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?
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