Re:CLI Guidelines – A guide to help you write better command...
by alpaca128 on Saturday December 05, 2020 @06:14AM
(#25313632)
I find it interesting how GUI and CLI drift apart so far in this
area. Powerful GUI software for specialised tasks is often
overloaded with buttons and toolbars everywhere because the user
needs to be able to click them. The terminal is the complete
opposite, instead of clicking through menus to find the right
option(or use a ton of keyboard shortcuts) you have to know what
to type. But it's also very efficient and flexible, and in
exchange for more difficult discoverability of features it
circumvents menus completely.
Re:CLI Guidelines – A guide to help you write better command...
by anamexis on Saturday December 05, 2020 @10:35PM
(#25320798)
That's true, but I think GUI drifts back when you consider the arcane keyboard shortcuts a good GUI has for power users.
Re:CLI Guidelines – A guide to help you write better command...
by throwaway201103 on Friday December 04, 2020 @09:53PM
(#25311257)
These old commands are also terse because the user was very often working at a teletype at 110 baud, or some other very slow type of terminal.
As a sibling comment mentions, these commands were (are) commonly composed into scripts. As the name implies, however, a script is just a playbook for a series of commands to run. Given the terminals of the era, I'm sure short commands/variables/etc. were appreciated in scripts as well, but it seems to me that the primary motivation for optimizing input speed would be the use of these commands in an interactive environment.
A few examples of these core short program names: ls, cat, cp, rm, wc, uniq, cmp, diff, od, dd, tail, tr, etc.