4 ms·

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 ma

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).
  - Annatar 10y ago
    As for "cop out" — it's not like long options prevent you from writing good documentation! Those are two different, unrelated things. I must vehemently disagree with you and anyone else that these are two different, unrelated things, because I assert that there is a direct link between poorly or non-existent manual pages and --long-options, and no amount of punting to GNU texinfo, a solution proprietary to GNU/Linux, will change that. As noted in a related post, brevity in UNIX has to do with ergonomy, and nothing whatsoever to do with link speed. That git has so many options is either a failure of the interface, or poor documentation, or both (after trying out git, I'm completely skipping it and going from Mercurial to Bitkeeper, and the interface is one of the reasons for that). Actually Mercurial is a perfect example of just how irritating and anti ergonomic long options are, example: hg revert --no-backup some/file so much typing. Unbelievably frustrating and irritating to no end. As for zsh, how could it possibly know how to complete the long options of every single application on the system? How does that work? Also a point on your coreutils argument: two letter application names, where names can be meaningfully shortened, is good design every programmer who cares about their and their users' productivity should follow; where that isn't possible, the name should be shortened as much as it can be. For example, I wrote a program which builds a list of SVR4 package dependencies, but instead of naming it find_dependencies, I named it fndeps. The manual page should explain what the program does, not the --long-options; software without a comprehensive manual page on UNIX is fundamentally shoddy software.

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).
- Annatar 10y ago
  As for "cop out" — it's not like long options prevent you from writing good documentation! Those are two different, unrelated things. I must vehemently disagree with you and anyone else that these are two different, unrelated things, because I assert that there is a direct link between poorly or non-existent manual pages and --long-options, and no amount of punting to GNU texinfo, a solution proprietary to GNU/Linux, will change that. As noted in a related post, brevity in UNIX has to do with ergonomy, and nothing whatsoever to do with link speed. That git has so many options is either a failure of the interface, or poor documentation, or both (after trying out git, I'm completely skipping it and going from Mercurial to Bitkeeper, and the interface is one of the reasons for that). Actually Mercurial is a perfect example of just how irritating and anti ergonomic long options are, example: hg revert --no-backup some/file so much typing. Unbelievably frustrating and irritating to no end. As for zsh, how could it possibly know how to complete the long options of every single application on the system? How does that work? Also a point on your coreutils argument: two letter application names, where names can be meaningfully shortened, is good design every programmer who cares about their and their users' productivity should follow; where that isn't possible, the name should be shortened as much as it can be. For example, I wrote a program which builds a list of SVR4 package dependencies, but instead of naming it find_dependencies, I named it fndeps. The manual page should explain what the program does, not the --long-options; software without a comprehensive manual page on UNIX is fundamentally shoddy software.