5 ms·

There’s a special place in hell for those pushing long argument names with single hyphens. One hyphen is for shorthand, two for long name.

jonpalmisc 5y ago
Clang, swiftc, etc. would like a word with you... :) (It bothers me too.)
- sp332 5y ago
  -fpic is a single letter option, -f, followed by the parameter pic. Clang still uses two hyphens for long options including --help.
  - lifthrasiir 5y ago
    There are tons of options that start with -f and can't be decomposed in that way [1, e.g. -framework]. They are essentially atomic options with a loose naming convention. [1] https://clang.llvm.org/docs/ClangCommandLineReference.html https://clang.llvm.org/docs/ClangCommandLineReference.html
    - IgorPartola 5y ago
      Correct. You cannot use “ramework” as an argument to “-f”. Instead use two dashes and it is unambiguous.
      - lifthrasiir 5y ago
        It took me some thoughts to realize what you wanted to say, and you are incorrect: there is no single option `-f` in cc options! `-f` is just a common prefix of hundreds of independent options, like `-fsanitize=...` (which can't be used as `-f sanitize=...`). As I've iterated before, those prefixes mostly represent broad categories of options and not hard and fast rules: `-g` for debug, `-i` for directories, `-m` for target architectures, `-W` for warnings, and `-f` for virtually everything else.
        deleted 5y ago
        [deleted]
  - hsbauauvhabzb 5y ago
    But maybe we should talk about the lack of space character between the flag and the argument…
    - account42 5y ago
      That's just how short options with arguments work in getopt POSIX land: '-oARG' is equivalent to '-o' 'ARG' just like '--option=ARG' is equivalent to '--option' 'ARG' (for GNU long options). This means that you cannot chain any other short options after one with an (optional) argument but otherwise does not cause any problems.
      - hsbauauvhabzb 5y ago
        Yes not every Linux/unix arg parser conforms to posix, some require a space, others do not.
- smaudet 5y ago
  saneclang, saneswift, (sanegcc?) cli wrappers around clang, swift which fix the insane porcelains of those toolchains. We built a million GUIs for these, why did we never build CLIs for bad CLIs?
- account42 5y ago
  To be fair to Clang, the -arguments are inherited from GCC for compatibility (which perhaps inherited them from other CCs) and then extended from there in the most consistent way possible. Similarily, clang-cl supports cl.exe-style flags for drop-in compatibility.
lifthrasiir 5y ago
If there are lots of long argument names and many of them are freqently used, there is not much point for shorthands though. Better to treat single-letter "shorthands" as their canonical names in that case (e.g. compilers). Of course you can still argue that all of them should have two hyphens.
IgorPartola 5y ago
Yes. Also for people who insist that you use —-help but won’t accept -h.
- sirl1on 5y ago
  >$ footool --help Unrecognized bar "--help", aborting! Use: "footool help" to display usage information >$ man footool No manual entry for footool
- account42 5y ago
  Probably a typo but requiring `—-help` with em dash would be another level of evil.
- Annatar 5y ago
  The worst offenders are the ones who even put the logic in to let one know that they knew exactly what one meant, but instead of accepting it they purposely throw an error, and adding insult to injury, telling one what one should have provided. Those people are psychopathic abusers, and for some bizarre reason seem to be drawn to computers. I haven't figured out why yet.
  - isitmadeofglass 5y ago
    Like “exit” in the Python repl, Which,knowing perfectly well what you wanted to do, will bark back “use exit()”. And only now, decades later it’s actually being fixed, but you still have evil bastards complaining that it should not do what you expect.
  - recursive 5y ago
    Yes. git push does this.
mseepgood 5y ago
No, that's just GNU.
- int_19h 5y ago
  Originally, yes. Now it's much more widespread, because it turned out to be a good idea to have consistent argument syntax.
anilakar 5y ago
> long argument names with single hyphens. Also --long_options_with_snake_case
- settrans 5y ago
  Might I caution you away from any tools built with the Abseil flags library.
  - anilakar 5y ago
    Looks like a leaky abstraction, in which a negligible amount of time saved in development (by mapping command line options directly to identifiers) results in UX woes.
throwaway787544 5y ago
twic 5y ago
For whatever reason, the Java tools have had these from the beginning. It's rubbish but you get used to it. More recently, they have been using double hyphens for long flags. So now you don't even know which it will be! And of course, there are extra options hidden under -XX. And flags which take arguments use inconsistent separators. So a command line might look like this: java -agentpath:/opt/agent.jar --module-path /opt/modules -XX:HeapDumpPath=/tmp/heapdumps
- nl 5y ago
  > For whatever reason, the Java tools have had these from the beginning. The double hyphen thing was standardised by the GNU project. James Gosling didn't like GNU (I think based on something that happened in the Lisp days?).
ainar-g 5y ago
Funnily enough, find(1), one of the oldest Unix tools to still be somewhat actively used, had those from the very beginning. Although, arguably, find(1) can be considered an interpreter of a language of its own, like sed(1) and awk(1), as opposed to a utility that accepts flags. See the Unix v5 man page source: https://github.com/aap/unixman/blob/master/v5man/man1/find.1 https://github.com/aap/unixman/blob/master/v5man/man1/find.1. (If anyone has a link where those are rendered, please let me know.)
- anjbe 5y ago
  According to Dennis Ritchie, find(1) was developed by a different group at Bell Labs which explains the difference in style. “…We were somewhat put off by the syntax of their things. However, they were clearly quite useful, and they were accepted.” http://doc.cat-v.org/unix/find-history http://doc.cat-v.org/unix/find-history
  - Trouble_007 5y ago
    Open a terminal in a directory; Find Files $ find|sort|egrep -i 'file.name' Find Text $ find|sort|egrep -iR 'text.in.files'
  - cryptonector 5y ago
    "It came from NJ" was a pejorative at Sun. Like, if you were staring at some awful piece of code in Solaris, and you were like, "who wrote this??" and asked around, and the answer you got was "it came from New Jersey", that meant it was part of SVR4.
lenkite 5y ago
By that strange logic, all the developers of the Go Programming Language deserve a special place in hell ? Why do I have to laboriously type two hypens for a readable option ? Causes finger pain especially when you have a large number of options.
- KronisLV 5y ago
  > Why do I have to laboriously type two hypens for a readable option? Suppose you have a CLI app that supports the following parameters: -e extrapolate your foos -h highlight your bars -l line up your bazs -p print the aforementioned as they're being processed So you might run the CLI as: cli -ep cli -hp cli -ehp cli -lp # a bunch of other combinations, including cli -ehlp # but since the order doesn't matter, also cli -help Do you see why that might be a problem with the short parameters? Now, most applications would reserve -h for help, so instead you'd still end up with the following: cli -help # so, the user wants to # -h get help information # -e extrapolate your foos # -l line up your bazs # -p print the aforementioned as they're being processed which does not make a lot of sense. That's why you'd normally have something like: -e --extrapolate extrapolate your foos -h --help get help information -i --highlight (-i seems close enough) highlight your bars -l --line line up your bazs -p --print print the aforementioned as they're being processed (though this is just an example, a lot of packages also use -v --verbose) So then there's no such confusion: cli -ielp # makes sense, a bunch of commands cli -help # still doesn't make (much) sense, help shorthand mixed in with arguments for data processing cli -h # makes sense, short hand for --help cli --help # verbose help command cli --highlight --extrapolate --line --print # also makes sense, just more verbose
  - lenkite 5y ago
    I don't get this. Why did you reserve '-h' for highlight in the first example ? And then you chose the long option form "-h/--help" to say the problem is now fixed. It seems an entirely artificial problem made by an originally bad choice. And has nothing to do with lack of double hyphens. "go -h" is same as "go help".
    - 5y ago
Annatar 5y ago
Oh, if only I could upvote this more! And even more torture and suffering is reserved for those morons who use --long-options "because they are easy to remember".
oakwhiz 5y ago
The LSI MegaRAIDb proprietary command line tool, MegaCli, is guilty of this and several other transgressions...

jonpalmisc 5y ago

Clang, swiftc, etc. would like a word with you... :) (It bothers me too.)

sp332 5y ago
-fpic is a single letter option, -f, followed by the parameter pic. Clang still uses two hyphens for long options including --help.
- lifthrasiir 5y ago
  There are tons of options that start with -f and can't be decomposed in that way [1, e.g. -framework]. They are essentially atomic options with a loose naming convention. [1] https://clang.llvm.org/docs/ClangCommandLineReference.html https://clang.llvm.org/docs/ClangCommandLineReference.html
  - IgorPartola 5y ago
    Correct. You cannot use “ramework” as an argument to “-f”. Instead use two dashes and it is unambiguous.
    - lifthrasiir 5y ago
      It took me some thoughts to realize what you wanted to say, and you are incorrect: there is no single option `-f` in cc options! `-f` is just a common prefix of hundreds of independent options, like `-fsanitize=...` (which can't be used as `-f sanitize=...`). As I've iterated before, those prefixes mostly represent broad categories of options and not hard and fast rules: `-g` for debug, `-i` for directories, `-m` for target architectures, `-W` for warnings, and `-f` for virtually everything else.
      - deleted 5y ago
        [deleted]
- hsbauauvhabzb 5y ago
  But maybe we should talk about the lack of space character between the flag and the argument…
  - account42 5y ago
    That's just how short options with arguments work in getopt POSIX land: '-oARG' is equivalent to '-o' 'ARG' just like '--option=ARG' is equivalent to '--option' 'ARG' (for GNU long options). This means that you cannot chain any other short options after one with an (optional) argument but otherwise does not cause any problems.
    - hsbauauvhabzb 5y ago
      Yes not every Linux/unix arg parser conforms to posix, some require a space, others do not.
smaudet 5y ago
saneclang, saneswift, (sanegcc?) cli wrappers around clang, swift which fix the insane porcelains of those toolchains. We built a million GUIs for these, why did we never build CLIs for bad CLIs?
account42 5y ago
To be fair to Clang, the -arguments are inherited from GCC for compatibility (which perhaps inherited them from other CCs) and then extended from there in the most consistent way possible. Similarily, clang-cl supports cl.exe-style flags for drop-in compatibility.

lifthrasiir 5y ago

If there are lots of long argument names and many of them are freqently used, there is not much point for shorthands though. Better to treat single-letter "shorthands" as their canonical names in that case (e.g. compilers). Of course you can still argue that all of them should have two hyphens.

IgorPartola 5y ago

Yes. Also for people who insist that you use —-help but won’t accept -h.

sirl1on 5y ago
>$ footool --help Unrecognized bar "--help", aborting! Use: "footool help" to display usage information >$ man footool No manual entry for footool
account42 5y ago
Probably a typo but requiring `—-help` with em dash would be another level of evil.
Annatar 5y ago
The worst offenders are the ones who even put the logic in to let one know that they knew exactly what one meant, but instead of accepting it they purposely throw an error, and adding insult to injury, telling one what one should have provided. Those people are psychopathic abusers, and for some bizarre reason seem to be drawn to computers. I haven't figured out why yet.
- isitmadeofglass 5y ago
  Like “exit” in the Python repl, Which,knowing perfectly well what you wanted to do, will bark back “use exit()”. And only now, decades later it’s actually being fixed, but you still have evil bastards complaining that it should not do what you expect.
- recursive 5y ago
  Yes. git push does this.

mseepgood 5y ago

No, that's just GNU.

int_19h 5y ago
Originally, yes. Now it's much more widespread, because it turned out to be a good idea to have consistent argument syntax.

anilakar 5y ago

> long argument names with single hyphens. Also --long_options_with_snake_case

settrans 5y ago
Might I caution you away from any tools built with the Abseil flags library.
- anilakar 5y ago
  Looks like a leaky abstraction, in which a negligible amount of time saved in development (by mapping command line options directly to identifiers) results in UX woes.

throwaway787544 5y ago

twic 5y ago

For whatever reason, the Java tools have had these from the beginning. It's rubbish but you get used to it. More recently, they have been using double hyphens for long flags. So now you don't even know which it will be! And of course, there are extra options hidden under -XX. And flags which take arguments use inconsistent separators. So a command line might look like this: java -agentpath:/opt/agent.jar --module-path /opt/modules -XX:HeapDumpPath=/tmp/heapdumps

nl 5y ago
> For whatever reason, the Java tools have had these from the beginning. The double hyphen thing was standardised by the GNU project. James Gosling didn't like GNU (I think based on something that happened in the Lisp days?).

ainar-g 5y ago

Funnily enough, find(1), one of the oldest Unix tools to still be somewhat actively used, had those from the very beginning. Although, arguably, find(1) can be considered an interpreter of a language of its own, like sed(1) and awk(1), as opposed to a utility that accepts flags. See the Unix v5 man page source: https://github.com/aap/unixman/blob/master/v5man/man1/find.1 https://github.com/aap/unixman/blob/master/v5man/man1/find.1. (If anyone has a link where those are rendered, please let me know.)

anjbe 5y ago
According to Dennis Ritchie, find(1) was developed by a different group at Bell Labs which explains the difference in style. “…We were somewhat put off by the syntax of their things. However, they were clearly quite useful, and they were accepted.” http://doc.cat-v.org/unix/find-history http://doc.cat-v.org/unix/find-history
- Trouble_007 5y ago
  Open a terminal in a directory; Find Files $ find|sort|egrep -i 'file.name' Find Text $ find|sort|egrep -iR 'text.in.files'
- cryptonector 5y ago
  "It came from NJ" was a pejorative at Sun. Like, if you were staring at some awful piece of code in Solaris, and you were like, "who wrote this??" and asked around, and the answer you got was "it came from New Jersey", that meant it was part of SVR4.

lenkite 5y ago

By that strange logic, all the developers of the Go Programming Language deserve a special place in hell ? Why do I have to laboriously type two hypens for a readable option ? Causes finger pain especially when you have a large number of options.

KronisLV 5y ago
> Why do I have to laboriously type two hypens for a readable option? Suppose you have a CLI app that supports the following parameters: -e extrapolate your foos -h highlight your bars -l line up your bazs -p print the aforementioned as they're being processed So you might run the CLI as: cli -ep cli -hp cli -ehp cli -lp # a bunch of other combinations, including cli -ehlp # but since the order doesn't matter, also cli -help Do you see why that might be a problem with the short parameters? Now, most applications would reserve -h for help, so instead you'd still end up with the following: cli -help # so, the user wants to # -h get help information # -e extrapolate your foos # -l line up your bazs # -p print the aforementioned as they're being processed which does not make a lot of sense. That's why you'd normally have something like: -e --extrapolate extrapolate your foos -h --help get help information -i --highlight (-i seems close enough) highlight your bars -l --line line up your bazs -p --print print the aforementioned as they're being processed (though this is just an example, a lot of packages also use -v --verbose) So then there's no such confusion: cli -ielp # makes sense, a bunch of commands cli -help # still doesn't make (much) sense, help shorthand mixed in with arguments for data processing cli -h # makes sense, short hand for --help cli --help # verbose help command cli --highlight --extrapolate --line --print # also makes sense, just more verbose
- lenkite 5y ago
  I don't get this. Why did you reserve '-h' for highlight in the first example ? And then you chose the long option form "-h/--help" to say the problem is now fixed. It seems an entirely artificial problem made by an originally bad choice. And has nothing to do with lack of double hyphens. "go -h" is same as "go help".
  - 5y ago

Annatar 5y ago

Oh, if only I could upvote this more! And even more torture and suffering is reserved for those morons who use --long-options "because they are easy to remember".

oakwhiz 5y ago

The LSI MegaRAIDb proprietary command line tool, MegaCli, is guilty of this and several other transgressions...