standards.info: User Interfaces
Go forward to Option Table
Go backward to Errors
Go up to Program Behavior
Go to the top op standards
Standards for Command Line Interfaces
Please don't make the behavior of a utility depend on the name used
to invoke it. It is useful sometimes to make a link to a utility with
a different name, and that should not change what it does.
Instead, use a run time option or a compilation switch or both to
select among the alternate behaviors.
Likewise, please don't make the behavior of the program depend on the
type of output device it is used with. Device independence is an
important principle of the system's design; do not compromise it merely
to save someone from typing an option now and then.
If you think one behavior is most useful when the output is to a
terminal, and another is most useful when the output is a file or a
pipe, then it is usually best to make the default behavior the one that
is useful with output to a terminal, and have an option for the other
behavior.
Compatibility requires certain programs to depend on the type of
output device. It would be disastrous if `ls' or `sh' did not do so in
the way all users expect. In some of these cases, we supplement the
program with a preferred alternate version that does not depend on the
output device type. For example, we provide a `dir' program much like
`ls' except that its default output format is always multi-column
format.
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 (*note 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'.
`--version'
This option should direct the program to 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.
`--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.
Created Wed Sep 1 16:42:53 2004 on bee with info_to_html version 0.9.6.