Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Use Long Options in Scripts

matklad.github.io

Post reply on HN
Print view View original

101–110 of 157 posts

Re: Use Long Options in Scripts

#101

Post by SAI_Peregrinus »

mplanchard wrote: post #97
delusional wrote: post #63

Earlier quoted context omitted.

nix didn't solve your issue here. nix didn't do anything. You're just describing the benefit of a reproducible development environment. You could do the same thing with brew, pacman, apt, or by just compiling every package from source from some huge mirror. It's exactly the same thing people initially loved about docker or vagrant.

Sure, but it works on Mac and Linux and doesn’t require virtualization. I think brew might qualify, but it can’t define which environment variables should be available in the developer shell or which hooks to run upon entry. I don’t think any of the other options you specified can manage the same thing.

Also you can use nix-shell as the shebang, and then pass a second line to tell it what program to use to interpret the rest of the script and all of its dependencies. It'll fetch the shell utilities in the versions you want when the script is run.

Re: Use Long Options in Scripts

#102

Post by mplanchard »

userbinator wrote: post #26
mplanchard wrote: post #17

Earlier quoted context omitted.

Because not everyone has 20 or more years of flag memory from using Linux, and they’ve also got to maintain the scripts. If you’re not familiar with every arcane invocation of find or tar or whatever, or even if it’s just been a while, the long options are a godsend when you’re skimming a script trying to figure out what it’s doing.

Because not everyone has 20 or more years of flag memory from using Linux It's called learning , apparently something that is now being eschewed in favour of quick superficiality (and making developers more replaceable --- with AI or unskilled offshore labour.) No wonder "modern" software is almost always total shit. "But I don't have the time to learn," you complain, but ask yourself this instead: Why do you never h…

As someone who works on a team of people with different levels of experience, where understanding is more important than some self-inflicted purity test of their unix chops, I will always either do long options or, where that’s not possible, a comment explaining the short options.

No one is complaining about not having time to learn: you’re arguing against a strawman. The point is not to discourage learning, it’s to encourage clarity in a context where it can at times be critically important.

Re: Use Long Options in Scripts

#103

Post by mplanchard »

xyzzy9563 wrote: post #83
mplanchard wrote: post #17

Earlier quoted context omitted.

Because not everyone has 20 or more years of flag memory from using Linux, and they’ve also got to maintain the scripts. If you’re not familiar with every arcane invocation of find or tar or whatever, or even if it’s just been a while, the long options are a godsend when you’re skimming a script trying to figure out what it’s doing.

You can always copy+paste it into an LLM and have it explain the options in 5 seconds.

I like how programmers are all about locality of reasoning and avoiding context switches until the context switch is “go paste it into an LLM”

Re: Use Long Options in Scripts

#104

Post by xyzzy9563 »

mplanchard wrote: post #103
xyzzy9563 wrote: post #83

Earlier quoted context omitted.

You can always copy+paste it into an LLM and have it explain the options in 5 seconds.

I like how programmers are all about locality of reasoning and avoiding context switches until the context switch is “go paste it into an LLM”

Just wait 5 years when 99% of code is written by LLM agents.

Re: Use Long Options in Scripts

#105

Post by Timon3 »

apgwoz wrote: post #96
amelius wrote: post #88

Before invoking a command, always first check if the length of the command is not longer than ARG_MAX. For example, if this is your command: grep --ignore-case --files-with-matches -- "hello" *.c Then invoke it as follows: CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c" ARG_MAX=$(getconf ARG_MAX) CMD_LEN=${#CMD} if (( CMD_LEN > ARG_MAX )); then echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($A…

You should always type check your shell scripts as well. For example, you just: $ shelltypes script.sh # Welcome to shelltypes v 3.23.2 # type ‘help’ if you’re stuck >>> {1) # import POSIX;; Importing 73 items. >>> {2} # append loadpath “/opt/local/shelltypes/base”;; >>> {3} # import base::YOURPROJECT;; Importing 15 items. >>> {4} # check “YOURSCRIPT.sh” Parsing YOURSCRIPT.sh. Reticulating splines. Expanding aliases.…

Where does "shelltypes" come from? I can't find anything on DuckDuckGo or Google, but this seems like it would be very useful.

Re: Use Long Options in Scripts

#106

Post by p_wood »

amelius wrote: post #88

Before invoking a command, always first check if the length of the command is not longer than ARG_MAX. For example, if this is your command: grep --ignore-case --files-with-matches -- "hello" *.c Then invoke it as follows: CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c" ARG_MAX=$(getconf ARG_MAX) CMD_LEN=${#CMD} if (( CMD_LEN > ARG_MAX )); then echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($A…

> eval "$CMD"

That means you will eval all the filenames, so if you have a file with spaces in it will appear as two files, if there is a `$` in the name it will trigger parameter substitution and so on for the other shell meta-characters.

Re: Use Long Options in Scripts

#107

Post by amelius »

p_wood wrote: post #106
amelius wrote: post #88

Before invoking a command, always first check if the length of the command is not longer than ARG_MAX. For example, if this is your command: grep --ignore-case --files-with-matches -- "hello" *.c Then invoke it as follows: CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c" ARG_MAX=$(getconf ARG_MAX) CMD_LEN=${#CMD} if (( CMD_LEN > ARG_MAX )); then echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($A…

> eval "$CMD" That means you will eval all the filenames, so if you have a file with spaces in it will appear as two files, if there is a `$` in the name it will trigger parameter substitution and so on for the other shell meta-characters.

Yes, that could be true. I'm not great in Bash. Be careful. These types of error are why I don't use Bash. I just wanted to give an example in a commonly used scripting language. The main point here is to check ARG_MAX.

Re: Use Long Options in Scripts

#108

Post by amelius »

_huayra_ wrote: post #100
amelius wrote: post #88

Before invoking a command, always first check if the length of the command is not longer than ARG_MAX. For example, if this is your command: grep --ignore-case --files-with-matches -- "hello" *.c Then invoke it as follows: CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c" ARG_MAX=$(getconf ARG_MAX) CMD_LEN=${#CMD} if (( CMD_LEN > ARG_MAX )); then echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($A…

On my system, `getconf ARG_MAX` is over 2m. I have seen some heinously long cmdline strings, but nothing close to that. Usually when invocations have creeped up into the O(1k) character limit at places I've worked, I've implemented a "yaml as cmdline args" option to just pass a config file instead. Have you seen scenarios where this is actually limiting?

Yes, if *.c expands to a string over 2m. Maybe that is a lot for .c files, but it may easily happen with .tiff and a folder full of images used for training a deep learning model, for example.

Re: Use Long Options in Scripts

#109

Post by amelius »

apgwoz wrote: post #96
amelius wrote: post #88

Before invoking a command, always first check if the length of the command is not longer than ARG_MAX. For example, if this is your command: grep --ignore-case --files-with-matches -- "hello" *.c Then invoke it as follows: CMD="grep --ignore-case --files-with-matches -- \"hello\" *.c" ARG_MAX=$(getconf ARG_MAX) CMD_LEN=${#CMD} if (( CMD_LEN > ARG_MAX )); then echo "Error: Command length ($CMD_LEN) exceeds ARG_MAX ($A…

You should always type check your shell scripts as well. For example, you just: $ shelltypes script.sh # Welcome to shelltypes v 3.23.2 # type ‘help’ if you’re stuck >>> {1) # import POSIX;; Importing 73 items. >>> {2} # append loadpath “/opt/local/shelltypes/base”;; >>> {3} # import base::YOURPROJECT;; Importing 15 items. >>> {4} # check “YOURSCRIPT.sh” Parsing YOURSCRIPT.sh. Reticulating splines. Expanding aliases.…

I don't know shelltypes, and it sounds like a linter for shell scripts.

Does shelltypes warn against a failure to check for ARG_MAX?

Post reply on HN