5 ms·

I'd expand on this and say every command line program should support GNU getopt_long() syntax, since this is the most popular syntax for command line interfaces

by Annatar 10y ago

I'd expand on this and say every command line program should support GNU getopt_long() syntax, since this is the most popular syntax for command line interfaces and it saves having to guess the syntax when using a program for the first time. One of the greatest crimes which GNU is not UNIX has committed are the --long-options, and that horrible practice stems from the fact that command line applications on GNU/Linux have poorly designed usage displays, and even worse (often non-existent) manual pages, and when there is a manual page, it lacks an EXAMPLES section, in stark contrast to UNIX systems (Solaris, HP-UX and SmartOS are exemplary). Ease of UNIX and efficiency thereof comes from brevity, and that particularly concerns command line options: the lowest amount of typing possible is the goal. The solution is not to invent an arbitrary and horrible convention, but to design better usage output, and to deliver high quality manual pages with lots of examples. Treat the root cause, not the symptom.

lobster_johnson 10y ago
The quality of GNU documentation has absolutely nothing to do with the merits or demerits of option styles. Not sure why you conflate the two. The GNU style makes things more explicit and readable, which is why people love it -- long options have been implemented far and wide outside of GNU. And it has one nice feature: It lets you treat short options as concatenable (so instead of "-v -f" you can just do "-vf") without ever accidentally conflicting with long options.
- Annatar 10y ago
  Because --long-option is way to cop out of writing a good quality usage output and a comprehensive manual page, as well as putting undue burden on the user to type more than is or should be necessary. Why do you think move is mv, list is ls, copy is cp, and remove is rm? And how long did it take to learn cp -p, ls -al, or rm -i? Ergonomy was and remains an extremely important topic in UNIX usage, and --long-option something or --long-option=something completely undermines that. -vf usage has absolutely nothing whatsoever to do with GNU getopt; it is the core functionality of both getopt(1), getopts(1), getopt(3C), and getopts(3C).
  - Ar-Curunir 10y ago
    No, the names are shortened because the original Unix was meant to be used over slow connections, and every character not typed was time saved in command execution. We don't have those concerns now, and so to make code unreadable for the sake of conciseness is not really useful.
    - Annatar 10y ago
      The names were shortened becuause the terminals had keyboards very similar to a typewriter, and stdout / stderr was a built-in printer, so mistakes were costly, and time consuming: http://www.tpsoft.com/museum_images/Teletype%20ASR-33%201.JPG http://www.tpsoft.com/museum_images/Teletype%20ASR-33%201.JP... https://en.wikipedia.org/wiki/Ken_Thompson#/media/File:Ken_Thompson_(sitting)_and_Dennis_Ritchie_at_PDP-11_(2876612463).jpg https://en.wikipedia.org/wiki/Ken_Thompson#/media/File:Ken_T... the ergonomy came first and foremost, not the slow links, and the ergonomy still plays an extremely important role on UNIX and UNIX-like systems, even today, because more typing and mistakes are still time consuming; those factors haven't gone away, and no link, however fast, can help with that. Ergonomy is extremely important on UNIX. It's one of the major reasons for preferring the command line as opposed to a graphical user interface. To test this: run non-customized /bin/ksh and see how fast you're able to type long command names without [TAB] completion and command history, and what your input error rate will be. You can even use a modern shell, like tcsh or zsh which have extremely powerful command history and autocompletion facilities, and see how well you fare with the shell completion of --some-long-option=/path/to/somewhere. You can even use bash and see how well it will complete --some-option for you. The message here is: if you're developing a command line application, please do not use --long-options, and please consider ergonomy very carefully. Save your users typing, and think about how you can reduce their error rates. --long-option isn't the way to do either of those things, it actually makes things more strenuous and slows one down.
  - atombender 10y ago
    I'm sorry, but that smacks of post-rationalization. Brevity used to be a benefit in the old days with slow connections, but the examples you give are also a small set of super-frequently-used coreutils commands. There are plenty of less core commands where brevity is a hindrance, not a helper, to understanding. For example, git has so many options that short options isn't even feasible for most of them. As for "cop out" — it's not like long options prevent you from writing good documentation! Those are two different, unrelated things. If my tool has an argument "--force", that's sort of self-documenting, to be sure, which "-f" isn't. But most tools do need to document exactly what "--force" does, irrespective of whether it's a long option. GNU's lack of documentation can't be claimed on option style. Your argument also sets up another false dichotomy: The presence of long options doesn't preclude to possibility of having short ones (--force maps to -f and so on), or indeed the possibility of short command names. PS. I noticed the other comment about shell autocompletion. I use zsh, and I autocompletion of long options works just fine (including just typing -- + tab and getting a list of available options).
tominous 10y ago
I like having the option to use both short and long forms. For common tasks the short form becomes second nature and saves time. For scripting or rare tasks I appreciate that the long form is self-documenting and less prone to typos.
countingteeth 10y ago
Non-existent manual pages? You forget the GNU convention; have a stub manual page that tells you to run "info" instead, so you can use the text browser to navigate 90 separate pages of two sentences each at your leisure.
- Annatar 10y ago
  If this is sarcasm, I can completely empathize with you; if it isn't, then the stub manual page is as good as non-existant, because no matter what, I am not going to waste my time struggling to navigate through a GNU texinfo page; I will just go to a real UNIX operating system which has high quality manual pages[1], and get my work done there, and that will be the end of it. [1] https://news.ycombinator.com/item?id=11927525 https://news.ycombinator.com/item?id=11927525

by Annatar 10y ago

lobster_johnson 10y ago

The quality of GNU documentation has absolutely nothing to do with the merits or demerits of option styles. Not sure why you conflate the two. The GNU style makes things more explicit and readable, which is why people love it -- long options have been implemented far and wide outside of GNU. And it has one nice feature: It lets you treat short options as concatenable (so instead of "-v -f" you can just do "-vf") without ever accidentally conflicting with long options.

Annatar 10y ago
Because --long-option is way to cop out of writing a good quality usage output and a comprehensive manual page, as well as putting undue burden on the user to type more than is or should be necessary. Why do you think move is mv, list is ls, copy is cp, and remove is rm? And how long did it take to learn cp -p, ls -al, or rm -i? Ergonomy was and remains an extremely important topic in UNIX usage, and --long-option something or --long-option=something completely undermines that. -vf usage has absolutely nothing whatsoever to do with GNU getopt; it is the core functionality of both getopt(1), getopts(1), getopt(3C), and getopts(3C).
- Ar-Curunir 10y ago
  No, the names are shortened because the original Unix was meant to be used over slow connections, and every character not typed was time saved in command execution. We don't have those concerns now, and so to make code unreadable for the sake of conciseness is not really useful.
  - Annatar 10y ago
    The names were shortened becuause the terminals had keyboards very similar to a typewriter, and stdout / stderr was a built-in printer, so mistakes were costly, and time consuming: http://www.tpsoft.com/museum_images/Teletype%20ASR-33%201.JPG http://www.tpsoft.com/museum_images/Teletype%20ASR-33%201.JP... https://en.wikipedia.org/wiki/Ken_Thompson#/media/File:Ken_Thompson_(sitting)_and_Dennis_Ritchie_at_PDP-11_(2876612463).jpg https://en.wikipedia.org/wiki/Ken_Thompson#/media/File:Ken_T... the ergonomy came first and foremost, not the slow links, and the ergonomy still plays an extremely important role on UNIX and UNIX-like systems, even today, because more typing and mistakes are still time consuming; those factors haven't gone away, and no link, however fast, can help with that. Ergonomy is extremely important on UNIX. It's one of the major reasons for preferring the command line as opposed to a graphical user interface. To test this: run non-customized /bin/ksh and see how fast you're able to type long command names without [TAB] completion and command history, and what your input error rate will be. You can even use a modern shell, like tcsh or zsh which have extremely powerful command history and autocompletion facilities, and see how well you fare with the shell completion of --some-long-option=/path/to/somewhere. You can even use bash and see how well it will complete --some-option for you. The message here is: if you're developing a command line application, please do not use --long-options, and please consider ergonomy very carefully. Save your users typing, and think about how you can reduce their error rates. --long-option isn't the way to do either of those things, it actually makes things more strenuous and slows one down.
- atombender 10y ago
  I'm sorry, but that smacks of post-rationalization. Brevity used to be a benefit in the old days with slow connections, but the examples you give are also a small set of super-frequently-used coreutils commands. There are plenty of less core commands where brevity is a hindrance, not a helper, to understanding. For example, git has so many options that short options isn't even feasible for most of them. As for "cop out" — it's not like long options prevent you from writing good documentation! Those are two different, unrelated things. If my tool has an argument "--force", that's sort of self-documenting, to be sure, which "-f" isn't. But most tools do need to document exactly what "--force" does, irrespective of whether it's a long option. GNU's lack of documentation can't be claimed on option style. Your argument also sets up another false dichotomy: The presence of long options doesn't preclude to possibility of having short ones (--force maps to -f and so on), or indeed the possibility of short command names. PS. I noticed the other comment about shell autocompletion. I use zsh, and I autocompletion of long options works just fine (including just typing -- + tab and getting a list of available options).

tominous 10y ago

I like having the option to use both short and long forms. For common tasks the short form becomes second nature and saves time. For scripting or rare tasks I appreciate that the long form is self-documenting and less prone to typos.

countingteeth 10y ago

Non-existent manual pages? You forget the GNU convention; have a stub manual page that tells you to run "info" instead, so you can use the text browser to navigate 90 separate pages of two sentences each at your leisure.

Annatar 10y ago
If this is sarcasm, I can completely empathize with you; if it isn't, then the stub manual page is as good as non-existant, because no matter what, I am not going to waste my time struggling to navigate through a GNU texinfo page; I will just go to a real UNIX operating system which has high quality manual pages[1], and get my work done there, and that will be the end of it. [1] https://news.ycombinator.com/item?id=11927525 https://news.ycombinator.com/item?id=11927525