getopt

A long-standing issue with command line programs was how to specify options; early programs used many ways of doing so, including single character options (-a), multiple options specified together (-abc is equivalent to -a -b -c), multicharacter options (-inum), options with arguments (-a arg, -inum 3, -a=arg), and different prefix characters (-a, +b, /c).

The getopt function was written to be a standard mechanism that all programs could use to parse command-line options so that there would be a common interface on which everyone could depend. As such, the original authors picked out of the variations support for single character options, multiple options specified together, and options with arguments (-a arg or -aarg), all controllable by an option string.

getopt dates back to at least 1980^[1] and was first published by AT&T at the 1985 UNIFORUM conference in Dallas, Texas, with the intent for it to be available in the public domain.^[2] Versions of it were subsequently picked up by other flavors of Unix (4.3BSD, Linux, etc.). It is specified in the POSIX.2 standard as part of the unistd.h header file. Derivatives of getopt have been created for many programming languages to parse command-line options.

A POSIX-standard companion function to getopt^[3] is getsubopt.^[4] It parses a string of comma-separated sub-options. It appeared in 4.4BSD (1995).^[5]

getopt is a system dependent function, and its behavior depends on the implementation in the C library. Some custom implementations like gnulib are available, however.^[6]

The conventional (POSIX and BSD) handling is that the options end when the first non-option argument is encountered, and that getopt would return -1 to signal that. In the glibc extension, however, options are allowed anywhere for ease of use; getopt implicitly permutes the argument vector so it still leaves the non-options in the end. Since POSIX already has the convention of returning -1 on -- and skipping it, one can always portably use it as an end-of-options signifier.^[6]

A GNU extension, getopt_long, allows parsing of more readable, multicharacter options, which are introduced by two dashes instead of one. The choice of two dashes allows multicharacter options (--inum) to be differentiated from single character options specified together (-abc). The GNU extension also allows an alternative format for options with arguments: --name=arg.^[6] This interface proved popular, and has been taken up (sans the permutation) by many BSD distributions including FreeBSD as well as Solaris.^[7] An alternative way to support long options is seen in Solaris and Korn Shell (extending optstring), but it was not as popular.^[8]

Another common advanced extension of getopt is resetting the state of argument parsing; this is useful as a replacement of the options-anyware GNU extension, or as a way to "layer" a set of command-line interface with different options at different levels. This is achieved in BSD systems using an optreset variable, and on GNU systems by setting optind to 0.^[6]

The command-line syntaxes for getopt-based programs is the POSIX-recommended Utility Argument Syntax. In short:^[9]

• Options are single-character alphanumerics preceded by a - (hyphen-minus) character.
• Options can take an argument, mandatory or optional, or none.
• In order to specify that an option takes an argument, include : after the option name (only during initial specification)
• When an option takes an argument, this can be in the same token or in the next one. In other words, if o takes an argument, -ofoo is the same as -o foo.
• Multiple options can be chained together, as long as the non-last ones are not argument taking. If a and b take no arguments while e takes an optional argument, -abe is the same as -a -b -e, but -bea is not the same as -b -e a due to the preceding rule.
• All options precede non-option arguments (except for in the GNU extension). -- always marks the end of options.

Extensions on the syntax include the GNU convention and Sun's CLIP specification.^[10][11]

The getopt manual from GNU specifies such a usage for getopt:^[12]

#include <unistd.h>

int getopt(int argc, char * const argv[],
           const char *optstring);

Here the argc and argv are defined exactly like they are in the C main function prototype; i.e., argc indicates the length of the argv array-of-strings. The optstring contains a specification of what options to look for (normal alphanumerals except W), and what options to accept arguments (colons). For example, "vf::o:" refers to three options: an argumentless v, an optional-argument f, and a mandatory-argument o. GNU here implements a W extension for long option synonyms.^[12]

getopt itself returns an integer that is either an option character or -1 for end-of-options.^[12] The idiom is to use a while-loop to go through options, and to use a switch-case statement to pick and act on options. See the example section of this article.

To communicate extra information back to the program, a few global extern variables are referenced by the program to fetch information from getopt:

extern char *optarg;
extern int optind, opterr, optopt;

optarg

A pointer to the argument of the current option, if present. Can be used to control where to start parsing (again).

optind

Where getopt is currently looking at in argv.

opterr

A boolean switch controlling whether getopt should print error messages.

optopt

If an unrecognized option occurs, the value of that unrecognized character.

The GNU extension getopt_long interface is similar, although it belongs to a different header file and takes an extra option for defining the "short" names of long options and some extra controls. If a short name is not defined, getopt will put an index referring to the option structure in the longindex pointer instead.^[12]

#include <getopt.h>

int getopt_long(int argc, char * const argv[],
                const char *optstring,
                const struct option *longopts, int *longindex);

Shell script programmers commonly want to provide a consistent way of providing options. To achieve this goal, they turn to getopts and seek to port it to their own language.

The first attempt at porting was the program getopt, implemented by Unix System Laboratories (USL). This version was unable to deal with quoting and shell metacharacters, as it shows no attempts at quoting. It has been inherited to FreeBSD.^[13]

In 1986, USL decided that being unsafe around metacharacters and whitespace was no longer acceptable, and they created the builtin getopts command for Unix SVR3 Bourne Shell instead. The advantage of building the command into the shell is that it now has access to the shell's variables, so values could be written safely without quoting. It uses the shell's own variables to track the position of current and argument positions, OPTIND and OPTARG, and returns the option name in a shell variable.

In 1995, getopts was included in the Single UNIX Specification version 1 / X/Open Portability Guidelines Issue 4.^[14] Now a part of the POSIX Shell standard, getopts have spread far and wide in many other shells trying to be POSIX-compliant.

getopt was basically forgotten until util-linux came out with an enhanced version that fixed all of old getopt's problems by escaping. It also supports GNU's long option names.^[15] On the other hand, long options have been implemented rarely in the getopts command in other shells, ksh93 being an exception.

getopt is a concise description of the common POSIX command argument structure, and it is replicated widely by programmers seeking to provide a similar interface, both to themselves and to the user on the command-line.

• C: non-POSIX systems do not ship getopt in the C library, but gnulib^[6] and MinGW (both accept GNU-style), as well as some more minimal libraries, can be used to provide the functionality.^[16] Alternative interfaces also exist:
  • The popt library, used by RPM package manager, has the additional advantage of being reentrant.
  • The argp family of functions in glibc and gnulib provides some more convenience and modularity.
• D programming language: has getopt module in the D standard library.
• Go: comes with the flag package,^[17] which allows long flag names. The getopt package ^[18] supports processing closer to the C function. There is also another getopt package ^[19] providing interface much closer to the original POSIX one.
• Haskell: comes with System.Console.GetOpt, which is essentially a Haskell port of the GNU getopt library.^[20]
• Java: There is no implementation of getopt in the Java standard library. Several open source modules exist, including gnu.getopt.Getopt, which is ported from GNU getopt,^[21] and Apache Commons CLI.^[22]
• Lisp: has many different dialects with no common standard library. There are some third party implementations of getopt for some dialects of Lisp. Common Lisp has a prominent third party implementation.
• Free Pascal: has its own implementation as one of its standard units named GetOpts. It is supported on all platforms.
• Perl programming language: has two separate derivatives of getopt in its standard library: Getopt::Long^[23] and Getopt::Std.^[24]
• PHP: has a getopt function.^[25]
• Python: contains a module in its standard library based on C's getopt and GNU extensions.^[26] Python's standard library also contains other modules to parse options that are more convenient to use.^[27][28]
• Ruby: has an implementation of getopt_long in its standard library, GetoptLong. Ruby also has modules in its standard library with a more sophisticated and convenient interface. A third party implementation of the original getopt interface is available.
• .NET Framework: does not have getopt functionality in its standard library. Third-party implementations are available.^[29]

• POSIX specification
• GNU getopt manual
• Full getopt port for Unicode and Multibyte Microsoft Visual C, C++, or MFC projects