Use Long Options in Scripts

matklad.github.io

297 points by OptionOfT a month ago


wahern - a month ago

Please DO NOT mix string interpolation and command execution, especially when a command is processed through the shell. Whatever your language, use a list-based or array-based execution API that passes arguments straight through to execv(2), execvp(2), etc, bypassing the shell.

susam - a month ago

I prefer long options too. However, while writing programs that need to invoke POSIX commands in a portable manner, short options are the only viable choice, as POSIX doesn't specify long options. For instance, see the specification for diff at <https://pubs.opengroup.org/onlinepubs/9799919799/utilities/d...>, or that of any POSIX utility listed at <https://pubs.opengroup.org/onlinepubs/9799919799/idx/utiliti...>.

That said, this is more of a corner case. In most scenarios, rather than relying on POSIX utilities, there are often better alternatives, such as using library bindings instead of spawning external processes. For example, instead of invoking grep, using something like libpcre could be a more efficient choice.

For non-POSIX utilities like git, hg, rg, ag, etc., using long options makes perfect sense.

dosourcenotcode - a month ago

Agree that long options should be used. But there is one caveat to consider: portability.

Sadly to this day not all BSD distributions have GNU style long options. And the ones that now do only got them fairly recently. So if you want portability you have to use short options as you weep with a bottle of vodka in hand.

teddyh - a month ago

Also, do not forget using “--” after all options, but before any dynamic arguments, just to be safe.

saagarjha - a month ago

Unfortunately, if you want your scripts to be portable to other POSIX systems you might have to use the short options, as the long ones are not standardized. You have to decide the tradeoff for yourself.

ratrocket - a month ago

I agree with this practice. Another benefit is it makes it easier (slightly, but still) to grep the man page for what the options do.

The corollary must be "write programs that take long options".

starkparker - a month ago

And put them on separate lines so you can track and git blame them more easily.

amelius - a month ago

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 ($ARG_MAX)." >&2
        exit 1
    fi

    eval "$CMD" # warning, evaluates filenames
croes - a month ago

> Long form options are much more self-explanatory for the reader.

And less prone to typos

ndegruchy - a month ago

This is one of my default rules for writing scripts. If the long option is available, use it. It makes too much sense to do so.

gabrielsroka - a month ago

Related 2013/2020 https://news.ycombinator.com/item?id=24518682

jFriedensreich - a month ago

The hype side of this is to always add instructions to use long options to the agent base prompt. Its much easier to spot mistakes and long options have the advantage to not do something completely different if they are wrong.

ashu1461 - a month ago

Reminds me of our code having llm generated regular expressions which are impossible to understand and the only way you can tweak it is giving it to llm to change.

- a month ago
[deleted]
vivzkestrel - a month ago

what if I or someone wrote a bot / script that searches across github for every shell script file that it can find and converts all short options into long options and opens a PR? Think dependabot but lets call it longabot or readabot?

wodenokoto - a month ago

Detracting from the message, but what is the `try shell.exec(" ...` thing?

pixelkink - a month ago

Prepares to launch in flaming rant... sigh You're right.

chasil - a month ago

If your goal is to help your coworkers, this is correct.

If not, it isn't.

ofrzeta - a month ago

and while you're at it, please alias --help to -h :-)

m463 - a month ago

not only long options, also multiple lines:

  somecmd \
      --option1 \
      --option2 $FOO \
      --option3 $BAR
malkia - a month ago

It depends...

sloooooooooooop - a month ago

[flagged]

johnisgood - a month ago

What is this? Use libgit2 or use a proper language where you do not need exec(), do it in Bash, or do it in C with libgit2 or with popen() or something. Using "system()" in C is never the right thing to do, the least you can do is using popen().

Not sure in which language you use "try shell.exec", but I am not even sure that it is the right way.

lapsed_lisper - a month ago

I used to think this, but now mostly (but weakly) don't. Long options buy expressiveness at the cost of density, i.e., they tend to turn "one-liners" into "N-liners". One-liners can be cryptic, but N-liners reduce how much program fits on the screen at once. I personally find it easier to look up flags than to have to page through multiple screenfuls to make sense of something. In this respect, ISTM short options are a /different/ way of helping a subsequent reader, by increasing the odds they see the forest, not just the trees.

userbinator - a month ago

Strongly, strongly disagree. This is a GNU-ism, and needlessly verbose. What's with people refusing to use the vast amount of memory in their brains and actually learning, instead lazily going for the lowest-common-denominator approach relying on "loanwords" from English?