Unix tradition encourages the use of command-line switches to
control programs, so that options can be specified from scripts. This
is especially important for programs that function as pipes or
filters. Three conventions for how to distinguish command-line options
from ordinary arguments exist; the original Unix style, the GNU style,
and the X toolkit style.
In the original Unix tradition, command-line options are single
letters preceded by a single hyphen. Mode-flag options that do not
take following arguments can be ganged together; thus, if
-a and -b are mode options,
-ab or -ba is also correct and
enables both. The argument to an option, if any, follows it
(optionally separated by whitespace). In this style, lowercase
options are preferred to uppercase. When you use uppercase options,
it's good form for them to be special variants of the lowercase
option.
The original Unix style evolved on slow ASR-33 teletypes that made
terseness a virtue; thus the single-letter options. Holding down the
shift key required actual effort; thus the preference for lower case,
and the use of “-” (rather than the perhaps more
logical “+”) to enable options.
The GNU style uses option keywords (rather than keyword letters)
preceded by two hyphens. It evolved years later when some of the
rather elaborate GNU utilities began to run out of single-letter
option keys (this constituted a patch for the symptom, not a cure for
the underlying disease). It remains popular because GNU options are
easier to read than the alphabet soup of older styles. GNU-style
options cannot be ganged together without separating whitespace. An
option argument (if any) can be separated by either whitespace or a
single “=” (equal sign) character.
The GNU double-hyphen option leader was chosen so that traditional
single-letter options and GNU-style keyword options could be
unambiguously mixed on the same command line. Thus, if your initial
design has few and simple options, you can use the Unix style without
worrying about causing an incompatible ‘flag day’ if you
need to switch to GNU style later on. On the other hand, if you are
using the GNU style, it is good practice to support single-letter
equivalents for at least the most common options.
The X toolkit style, confusingly, uses a single hyphen and
keyword options. It is interpreted by X toolkits that filter out and
process certain options (such as -geometry and
-display) before handing the filtered command line to
the application logic for interpretation. The X toolkit style is not
properly compatible with either the classic Unix or GNU styles, and
should not be used in new programs unless the value of being
compatible with older X conventions seems very high.
Many tools accept a bare hyphen, not associated with any option
letter, as a pseudo-filename directing the application to read from
standard input. It is also conventional to recognize a double hyphen
as a signal to stop option interpretation and treat all following
arguments literally.
Most Unix programming languages offer libraries that will parse
a command line for you in either classic-Unix or GNU style
(interpreting the double-hyphen convention as well).