Are there standards for Linux command line switches and arguments?

Question

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?

Answer 1

Generally, yes.

• IEEE
• GNU getopt

Answer 2

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

Answer 3

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.

Answer 4

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