Are there standards for Linux command line switches and arguments?

This is more about the invocation of a program, than any language or parser (though I'm sure choice of parser library can depend on this). See, I've used a lot of Linux command-line utilities. And there are some obvious patterns; '-' precedes a single letter for short options, multiple options that don't take arguments can be combined, '--' precedes long versions of options, and so on.

However, in some cases, capitalization is used to invert an option. So, '-d' might mean to run as a daemon, but '-D' would be to not run as a daemon. (Why not just omit the option if you don't want it? That's never been clear, but it's actually rather common, so I figure there must be some reason.) But in some programs, a capital is a completely unrelated option; if '-d' is run as daemon, '-D' might be to enable debug mode. Is there some kind of overarching principal behind this, and which is the best to choose? Or are we just dealing with "whatever works"?

There are also some commands that, in addition to (or instead of) options with arguments, just take lone arguments. cp is a good example of this; aside from a couple rarely used toggles, the last argument it receives is presumed to be the destination, and any arguments between the option list and the destination are presumed to be sources. Is there a rule of thumb when it's "okay" to rely on order like that, instead of using explicit option flags with arguments?

Generally, yes.

• IEEE
• GNU getopt

ESR has collected a lot of information about this in his book "The Art of UNIX Programming". Here's a snippet.

> -a
> All (without argument). If there is a GNU-style --all option, for -a to be anything but a synonym for it would be quite surprising. Examples: fuser(1), fetchmail(1). > > Append, as in tar(1). This is often paired with -d for delete. > > -b
> Buffer or block size (with argument). Set a critical buffer size, or (in a program having to do with archiving or managing storage > media) set a block size. Examples: du(1), df(1), tar(1). > > Batch. If the program is naturally interactive, -b may be used to > suppress prompts or set other options appropriate to accepting input > from a file rather than a human operator. Example: flex(1). > > -c
> Command (with argument). If the program is an interpreter that normally takes commands from standard input, it is expected that the > option of a -c argument will be passed to it as a single line of > input. This convention is particularly strong for shells and > shell-like interpreters. Examples: sh(1), ash(1), bsh(1), ksh(1), > python(1). Compare -e below. > > Check (without argument). Check the correctness of the file > argument(s) to the command, but don't actually perform normal > processing. Frequently used as a syntax-check option by programs that > do interpretation of command files. Examples: getty(1), perl(1).

See the full list at http://catb.org/~esr/writings/taoup/html/ch10s05.html

The Linux/GNU command line interface follows the POSIX standard. This is noted by GNU in their standards: http://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html.

Command line syntax is also part of the Single Unix Specification, though --long-options are a GNU innovation IIRC.

See here: http://pubs.opengroup.org/onlinepubs/7908799/xbd/utilconv.html

But yes, this standard is implemented as getopt.

A quick summary of the thread:

• You CLI should display help when missing or incorrect parameters in addition to the error message if any.

• You should use - for a single letter flag or option and -- for a long option, for instance -a and --all

• All programs should support two standard options: -v --version and -h --help.

• -h and --help => Give usage message and exit

• -v and --version => Show program version and exit

See the links (IEEE and GNU getopt) provided on this answer https://stackoverflow.com/a/8957246

Unix : single dash -

BSD : no dash

GNU : double dash --