59

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?

DigitalMan
  • 2,290
  • 5
  • 23
  • 32
  • 3
    There is no universal standard for command-line options, although the `getopt` conventions are a good starting point. To answer your question about inversion options, the default is usually specified in a configuration file, so you need both the force-enable and the force-disable toggles. – Borealid Jan 21 '12 at 22:20
  • Another good reference: Perl Long Options Processing: [Getopt::Long](https://perldoc.perl.org/Getopt/Long.html). – David Tonhofer Apr 19 '19 at 11:46
  • Does this answer your question? [Are there any standard exit status codes in Linux?](https://stackoverflow.com/questions/1101957/are-there-any-standard-exit-status-codes-in-linux) – oguz ismail May 24 '21 at 18:10

5 Answers5

35

Generally, yes.

cambunctious
  • 4,860
  • 3
  • 22
  • 35
ApriOri
  • 2,498
  • 27
  • 43
  • I'll probably be using getopt, though it's not too helpful on standards. That IEEE link, however, is extremely useful. – DigitalMan Jan 21 '12 at 22:38
  • In case you're about to implement a parser on your own: chances are high to find a parser library out there for about any language, there are parser libraries for java python c and I guess many others.so there's no need to reinvent the wheel. – ApriOri Jan 21 '12 at 22:45
  • 1
    Actually, it's my job to reinvent the wheel :P But since options are only parsed once, there's no need for it to go at ludicrous speed. I'll just drop in getopt. – DigitalMan Jan 21 '12 at 22:52
22

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

Patrick McElhaney
  • 52,844
  • 37
  • 123
  • 157
10

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.

showMeYourPython
  • 111
  • 1
  • 5
5

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

JCB
  • 86
  • 1
  • 4
-1

Unix : single dash -

BSD : no dash

GNU : double dash --

They_Call_Me_Nothing
  • 1
  • 1
    Can you cite resources? Looks like [GNU adds long versions to Posix options](https://www.gnu.org/software/libc/manual/html_node/Argument-Syntax.html) (assuming you mean that by "Unix"), but also allows single letter options with only one hyphen. – Robert May 24 '21 at 20:05
  • I can't share the actual resource due to reasons but I have read that this is a convention. Not that that cant be used interchangeably anywhere else, that is just a style. – They_Call_Me_Nothing May 29 '21 at 14:21