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.