4 ms·

`--help` is a GNU convention, which is why it's not as universal as you want it to be. Of course these days most Linux users interact with GNU tools and thus go

`--help` is a GNU convention, which is why it's not as universal as you want it to be. Of course these days most Linux users interact with GNU tools and thus go on to develop their own tools with the same convention, but it's the reason why non-GNU things like BSD utils or old `openssl` don't have it.

hylaride 2y ago
The GNU/BSD conventions are a lot of fun when you have some automation scripts that are used by people who are split between MacOS and Linux (or WSL on Windows).
kps 2y ago
`--long` options started with GNU (I think) but were soon adopted more widely. One of the really nice things about ksh that bash has neglected to copy is that its `getopts` easily handles long options and has built-in `--help`.
jerf 2y ago
It's 2025, not 1995. I'm about as sympathetic to this as "POSIX doesn't have it." For something like this, I don't care. I don't care how it's done. Heck, dump the help if you see any option with two dashes, if you're offended about long options. I don't care what other things dump help out too as long as --help does. But both -h and --help should always produce help, no matter what, no matter where you are, and I'd really like -help too, even if that is a bit more complicated. Though since I also want "a -h or a --help in the parameter list reliably makes it so that help is printed and NOTHING ELSE happens", "-help" should generally work as "-h" and "extra stuff that won't happen because -h is in play". It is an error for a program to both print the help and take any other action; should always do one XOR the other.
- benatkin 2y ago
  What about programs with such simple CLIs that they don’t have help? How about non English speakers who might be inclined to type —ayuda or something? In 2025 I think it should be more obvious that the shell is just running a program and programs have a variety of entry points and the same program can be distributed in different forms and that they might not all be self documenting.
  - f1shy 2y ago
    Personal opinion ahead, please don’t be offended: > What about programs with such simple CLIs that they don’t have help? It is crapware > about non English speakers who might be inclined to type —ayuda or something? Come on… really?! Most utilities use heavily english for option names. Even the names of the utilities. Should we have “buscar” instead of “find”, or “schneiden” for “cut”? What about iger instead of “grep”? That is just ridiculous! Please stop!
    - benatkin 2y ago
      I'm not offended hehe. I like small processes, and am into language learning, so my bias is showing. I think how things are, with most supporting --help, but not all, makes sense. I think what some are going for perhaps is that all programs to be run in the shell support --help. I think it could be normalized further by having a shell function get help for a command. For most it could pass --help, but it could handle the exceptions. So instead of running "foo --help" you could run "help foo", and it would run "foo --help" or "foo -h" or whatever, and it would be like man except instead of meaning show a manual page it could mean ask a program to document itself.
      - Arnavion 2y ago
        >I think it could be normalized further by having a shell function get help for a command. See PowerShell commandlets for a related precedent: https://learn.microsoft.com/en-us/powershell/scripting/developer/help/examples-of-comment-based-help?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/scripting/devel... Commandlets (shell functions) can annotate themselves and their parameters in a standard way, and then the shell's builtin help command parses that and presents it in a standard way. Though unfortunately this kind of integration only works for the commandlets, not arbitrary executables, because there's no standard for executables to expose such metadata to the shell.
    - Y_Y 2y ago
      I'm interested in how you've translated "grep". I would guess you chose something like mapping "Global Regular Expression Print" to "Imprimir Globalmente Expresión Regular". But of course "grep" isn't really an acronym, but a contraction of the ed (and ex) command "g/re/p". Surely you don't mean to alter the syntax along with the words!
- Arnavion 2y ago
  To be clear, the point of my comment was to give the reason that `--help` isn't universal, not to present any opinion on whether it should or should not be. (I myself am in the "go on to develop their own tools with the same convention" camp.)
f1shy 2y ago
If I’m working in Ubuntu, a GNU/Linux system, I expect to be pretty universal. I’m BSD and Solaris guy, but when I’m in linux, I spect linux. It should be part of PORTING a program, if the option is not supported.

hylaride 2y ago

The GNU/BSD conventions are a lot of fun when you have some automation scripts that are used by people who are split between MacOS and Linux (or WSL on Windows).

kps 2y ago

`--long` options started with GNU (I think) but were soon adopted more widely. One of the really nice things about ksh that bash has neglected to copy is that its `getopts` easily handles long options and has built-in `--help`.

jerf 2y ago

It's 2025, not 1995. I'm about as sympathetic to this as "POSIX doesn't have it." For something like this, I don't care. I don't care how it's done. Heck, dump the help if you see any option with two dashes, if you're offended about long options. I don't care what other things dump help out too as long as --help does. But both -h and --help should always produce help, no matter what, no matter where you are, and I'd really like -help too, even if that is a bit more complicated. Though since I also want "a -h or a --help in the parameter list reliably makes it so that help is printed and NOTHING ELSE happens", "-help" should generally work as "-h" and "extra stuff that won't happen because -h is in play". It is an error for a program to both print the help and take any other action; should always do one XOR the other.

benatkin 2y ago
What about programs with such simple CLIs that they don’t have help? How about non English speakers who might be inclined to type —ayuda or something? In 2025 I think it should be more obvious that the shell is just running a program and programs have a variety of entry points and the same program can be distributed in different forms and that they might not all be self documenting.
- f1shy 2y ago
  Personal opinion ahead, please don’t be offended: > What about programs with such simple CLIs that they don’t have help? It is crapware > about non English speakers who might be inclined to type —ayuda or something? Come on… really?! Most utilities use heavily english for option names. Even the names of the utilities. Should we have “buscar” instead of “find”, or “schneiden” for “cut”? What about iger instead of “grep”? That is just ridiculous! Please stop!
  - benatkin 2y ago
    I'm not offended hehe. I like small processes, and am into language learning, so my bias is showing. I think how things are, with most supporting --help, but not all, makes sense. I think what some are going for perhaps is that all programs to be run in the shell support --help. I think it could be normalized further by having a shell function get help for a command. For most it could pass --help, but it could handle the exceptions. So instead of running "foo --help" you could run "help foo", and it would run "foo --help" or "foo -h" or whatever, and it would be like man except instead of meaning show a manual page it could mean ask a program to document itself.
    - Arnavion 2y ago
      >I think it could be normalized further by having a shell function get help for a command. See PowerShell commandlets for a related precedent: https://learn.microsoft.com/en-us/powershell/scripting/developer/help/examples-of-comment-based-help?view=powershell-7.5 https://learn.microsoft.com/en-us/powershell/scripting/devel... Commandlets (shell functions) can annotate themselves and their parameters in a standard way, and then the shell's builtin help command parses that and presents it in a standard way. Though unfortunately this kind of integration only works for the commandlets, not arbitrary executables, because there's no standard for executables to expose such metadata to the shell.
  - Y_Y 2y ago
    I'm interested in how you've translated "grep". I would guess you chose something like mapping "Global Regular Expression Print" to "Imprimir Globalmente Expresión Regular". But of course "grep" isn't really an acronym, but a contraction of the ed (and ex) command "g/re/p". Surely you don't mean to alter the syntax along with the words!
Arnavion 2y ago
To be clear, the point of my comment was to give the reason that `--help` isn't universal, not to present any opinion on whether it should or should not be. (I myself am in the "go on to develop their own tools with the same convention" camp.)

f1shy 2y ago

If I’m working in Ubuntu, a GNU/Linux system, I expect to be pretty universal. I’m BSD and Solaris guy, but when I’m in linux, I spect linux. It should be part of PORTING a program, if the option is not supported.