Command-Line Interfaces - GNU Coding Standards

Next: Option Table, Previous: Graphical Interfaces, Up: Program Behavior

4.6 Standards for Command Line Interfaces

It is a good idea to follow the posix guidelines for the command-line options of a program. The easiest way to do this is to use getopt to parse them. Note that the GNU version of getopt will normally permit options anywhere among the arguments unless the special argument ‘--’ is used. This is not what posix specifies; it is a GNU extension.

Please define long-named options that are equivalent to the single-letter Unix-style options. We hope to make GNU more user friendly this way. This is easy to do with the GNU function getopt_long.

One of the advantages of long-named options is that they can be consistent from program to program. For example, users should be able to expect the “verbose” option of any GNU program which has one, to be spelled precisely ‘--verbose’. To achieve this uniformity, look at the table of common long-option names when you choose the option names for your program (see Option Table).

It is usually a good idea for file names given as ordinary arguments to be input files only; any output files would be specified using options (preferably ‘-o’ or ‘--output’). Even if you allow an output file name as an ordinary argument for compatibility, try to provide an option as another way to specify it. This will lead to more consistency among GNU utilities, and fewer idiosyncracies for users to remember.

All programs should support two standard options: ‘--version’ and ‘--help’. CGI programs should accept these as command-line options, and also if given as the PATH_INFO; for instance, visiting http://example.org/p.cgi/–help in a browser should output the same information as invoking ‘p.cgi --help’ from the command line.

--version

This option should direct the program to print information about its name, version, origin and legal status, all on standard output, and then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.

The first line is meant to be easy for a program to parse; the version number proper starts after the last space. In addition, it contains the canonical name for this program, in this format:

          GNU Emacs 19.30

The program's name should be a constant string; don't compute it from argv[0]. The idea is to state the standard or canonical name for the program, not its file name. There are other ways to find out the precise file name where a command is found in PATH.

If the program is a subsidiary part of a larger package, mention the package name in parentheses, like this:

          emacsserver (GNU Emacs) 19.30

If the package has a version number which is different from this program's version number, you can mention the package version number just before the close-parenthesis.

If you need to mention the version numbers of libraries which are distributed separately from the package which contains this program, you can do so by printing an additional line of version info for each library you want to mention. Use the same format for these lines as for the first line.

Please do not mention all of the libraries that the program uses “just for completeness”—that would produce a lot of unhelpful clutter. Please mention library version numbers only if you find in practice that they are very important to you in debugging.

The following line, after the version number line or lines, should be a copyright notice. If more than one copyright notice is called for, put each on a separate line.

Next should follow a brief statement that the program is free software, and that users are free to copy and change it on certain conditions. If the program is covered by the GNU GPL, say so here. Also mention that there is no warranty, to the extent permitted by law.

It is ok to finish the output with a list of the major authors of the program, as a way of giving credit.

Here's an example of output that follows these rules:

          GNU Emacs 19.34.5
          Copyright (C) 1996 Free Software Foundation, Inc.
          GNU Emacs comes with NO WARRANTY,
          to the extent permitted by law.
          You may redistribute copies of GNU Emacs
          under the terms of the GNU General Public License.
          For more information about these matters,
          see the files named COPYING.

You should adapt this to your program, of course, filling in the proper year, copyright holder, name of program, and the references to distribution terms, and changing the rest of the wording as necessary.

This copyright notice only needs to mention the most recent year in which changes were made—there's no need to list the years for previous versions' changes. You don't have to mention the name of the program in these notices, if that is inconvenient, since it appeared in the first line.

Translations of the above lines must preserve the validity of the copyright notices (see Internationalization). If the translation's character set supports it, the ‘(C)’ should be replaced with the copyright symbol, as follows:

Write the word “Copyright” exactly like that, in English. Do not translate it into another language. International treaties recognize the English word “Copyright”; translations into other languages do not have legal significance.

--help

This option should output brief documentation for how to invoke the program, on standard output, then exit successfully. Other options and arguments should be ignored once this is seen, and the program should not perform its normal function.

Near the end of the ‘--help’ option's output there should be a line that says where to mail bug reports. It should have this format:

          Report bugs to mailing-address.