
The -a to -z of Command-Line Options (2003) - polm23
http://www.catb.org/esr/writings/taoup/html/ch10s05.html
======
ktpsns
Wow, the fact that Mac OS Classic did not even have a command line interface
really baffles me. I looked it up and
[https://news.ycombinator.com/item?id=18646286](https://news.ycombinator.com/item?id=18646286)
\- it seems to be true.

It's ironic that in 2018, the terminal is more prominent then ever in any
developer scene (thinking only of package managers for diverse programming
languages), while in the 90s somehow people thought the GUI could solve all
problems, not only for the novices but also for computer experts.

~~~
chongli
Yes, classic Mac OS truly did not have a command line interface of any kind.
As a consequence, everything your application did must have had a GUI command
or preference corresponding to it.

Command line interfaces are powerful, yes, but they're also a crutch. It's
very easy to hide certain features by exposing them only through command line
flags or what have you. On classic Mac OS you could not do this; you needed to
attach every feature to a GUI control of some kind.

As a consequence, people came up with all kinds of GUI tools for pro/expert
users. Linux, comparison, treats GUI users as second class citizens and tends
to relegate them to only the most basic functionality.

~~~
jandrese
Eh, lots of stuff would be just stuffed into an appropriate resource and if
you wanted to hack it you would use ResEdit.

I miss ResEdit. Pretty much every Mac app in the day used the standard system
for managing their resources, so you could pick apart anything with ease using
ResEdit. I don't know of any modern equivalent for Unix/Windows/Mac programs.

~~~
derefr
I would think that the modern macOS equivalent to the "resource fork" is
simply an app bundle's Resources folder.

Also, regarding "burned-in configuration" resources—those are now found in the
app bundle's Info.plist :)

------
vram22
That whole book (not just the linked chapter about command-line options) -
i.e. TAOUP - The Art Of Unix Programming - by ESR (Eric Steven Raymond, of
Cathedral and Bazaar fame) - is good (although verbose and using many heavy
words and verbal flourishes in his trademark style). I've read most of it. The
Rules section stands out.

Being a Unix user and dev (above, not at the kernel level) for a long time
before reading it, it crystallized and verbalized for me many concepts and
unspoken techniques that are sort of hazily known and used but taken for
granted (although applied instinctively) - although I had also figured out and
sort of verbalized some of those on my own before reading the book.

Also, related, anyone interested in learning to write (not just use) their own
command-line utilities in C on Linux, may like to check out this tutorial I
wrote for IBM developerWorks:

[https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-
ar...](https://jugad2.blogspot.com/2014/09/my-ibm-developerworks-article.html)

It was on the site for long, got 30-40K views, and good ratings (4/5). Clients
and others I know have used the tutorial as a guide to creating production
command-line utilities. Follow the selpg links recursively to get to the PDF
of the article and the source code.

I first wrote the utility that is used as a case study in the article, for
production use at one of the largest motorcycle manufacturers in the world.

------
teddyh
See also the canonical table of long GNU-style options:

[http://www.gnu.org/prep/standards/html_node/Option-
Table.htm...](http://www.gnu.org/prep/standards/html_node/Option-
Table.html#Option-Table)

------
nouseforaname
Fun fact: -v typically stands for verbose except when using any "grep-like"
utilities such as pgrep, pkill, etc.

[edit] forgot to mention that for grep-like utilities -v negates the match.

This led to an unfortunate incident in which I attempted to get verbose output
from pkill and instead killed every single process on the machine _except_ for
my target. To make it worse I had no console access so I had to email another
team to reboot and explain what I did.

~~~
mehrdadn
I'll get crucified for saying this but this is one of the differences between
a CLI and a GUI. A button/menu item/etc. always tells you what it does (even
if it's just a brief description) before you click it. A command line
parameter, well, reduces the information redundancy to near zero... you have
to go out of your way to figure out its meaning.

~~~
WhitneyLand
Hasn’t anyone tried to add some kind of interactivity to command line typing
to eliminate this advantage?

Not something simplistic like keyword completion, more like the best state of
the art code editors or ides.

In those environments its just text based still, but can be incredibly rich
and efficient. You can get seamless acesss to info on any language command or
param, predictive code completion suggestions, based on machine learning,
easily refactor/correct parts of a line you’ve already started typing, etc.

The thing is it doesn’t have to get in the way if designed right. So someone
can also just sit down and blaze away typing and ignore it.

~~~
vram22
>Hasn’t anyone tried to add some kind of interactivity to command line typing
to eliminate this advantage?

One example: /bin/rm has the -i (for interactive option). Some people alias
'rm' (or if they are newbs, it is sometimes aliased for them by someone senior
in their org) to 'rm -i', which helps avoid deleting files by mistake, due to
typos or typing too fast. With -i, rm asks for confirmation before deleting
each file. This is more important in Unixes because most of them do not have
any undelete utility; nor does Windows, AFAIK, except for 3rd-party ones like
the Norton Utilities (does it still exist?), which need to be installed. And
installing the utility (if you can get it) _after_ an accidental delete, has
some chance of the utility getting installed onto disk blocks earlier occupied
by the deleted file.

------
dfox
One interesting thing to note is that IEEE 1003 says: "The -W (capital-W)
option shall be reserved for vendor options."

GNU getopt() uses this to make --foo and -Wfoo equivalent, but this is GNUism
of questionable utility.

I have feeling that original reason for this is that there historically was
libc which implemented wordexp(3) by exec'ing /bin/sh -W, but I have no way to
confirm that.

~~~
cyphar
I can imagine one of the reasons it might be useful is if you have a badly
written argument parser that only accepts single-dash commands, but you need
to pass a long argument (that gets shelled out). However, it's entirely opt-in
so I imagine this is not practically useful for most programs.

Notably, GCC's -W<foo> works the same way. You could do "gcc --all" if you
wanted to.

------
twic
What's the flag to specify a separator character?

    
    
      paths() { echo $PATH | tr : '\n'; }
      paths | cut -d / -f 3
      paths | column -s / -t
      paths | sort -t / -k 1
    

Any more?

~~~
jdeca568

      paths | awk -F / '{ print $1 }'
    

(edit: format)

------
pwaivers
> _-h Help. This is actually less common than one might expect offhand — for
> much of Unix 's early history developers tended to think of on-line help as
> memory-footprint overhead they couldn't afford._

This one does surprise me. It is almost always one of the first options I try.
That or "\--help".

~~~
cyphar
A friend of mine once had telnet'd into their (awful) ISP home router, and
started playing with the various commands. Not thinking, they typed "init -h"
and the router then promptly stopped routing packets. Turns out the (probably
custom-written) "init" automatically sets the runlevel to single-user mode,
and they handn't bothered to implement "-h".

For this reason, I always use "man <command>". The prevalence of "\--help" has
always bothered me since a badly-written command could start doing all sorts
of unexpected things, when you just wanted to see the documentation. I've seen
all sorts of ISV software not implement --help correctly. "man" always works.

~~~
jancsika
Ooh, good catch.

"man oven" = look up your oven model in your Home Manual

"oven -h" = turn your oven dial past "Broil" and hope it pops out a hidden
cheat sheet

------
amyjess
-p is also very commonly "password". It may take an argument, or it may cause the program to interactively prompt you for a password when you run it. Similarly, -k is often "key".

-a could also be "ask"; Gentoo, for example, uses it to ask you to confirm before proceeding with emerge.

-h is very often "host".

------
timerol
For everyone who finds this (and similar work by ESR) valuable, consider
supporting him on Patreon:
[https://www.patreon.com/esr](https://www.patreon.com/esr)

------
znpy
All I can think of, while noting all the numerous exceptions to the rule is
[https://www.xkcd.com/293/](https://www.xkcd.com/293/)

------
FASTasdf
pkill -v 1

~~~
lunchables
In my version of pkill the short version is specifically disabled.

-v, --inverse
    
    
                  Negates the matching.  This option is usually used in pgrep's context.  In pkill's context the short option is disabled to avoid accidental usage of the option

