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,

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.