Go to the first, previous, next, last section, table of contents.
Here is a feature comparison of AutoOpts and five other command line
parser generators. They all share a number of similarities:
-
They read a file that describes the program
options and produce code to parse command line options. Each has their
own format for describing options.
-
All versions support both short options (flags) and GNU-type long
options. clig, however, is unique in that you must choose one or the
other. Either way, clig options are introduced with a single hyphen.
The other packages identify long options with doubled hyphens.
-
They produce tailored code for parsing the command line.
-
They support the C programming language.
-
The global option state is stored in a global structure.
-
They produce usage text.
The 6 parsers compared are:
-
AutoOpts is a component of AutoGen. AutoGen has many
capabilities, but here we concentrate on the portion called
AutoOpts. AutoOpts is the most general of these programs,
and has the most extensive documentation. It is the only
one that supports shell and Scheme scripts as well as C programs.
-
clig can generate either C or Tcl option parsing code.
It can also process multiple arguments per single option.
-
genparse generates a wrapper around
getopts_long()
to parse the command line options.
-
gaa supports option input from a configuration file as well
as the command line. NOTE HOWEVER: gaa is not maintained.
-
gengetopt generates a C function that uses getopt_long
function to parse the command line options, to validate them
and fills a struct.
-
wyg uses flex and bison to generate a configuration file
parser, but uses getopt_long to parse the command line options.
Comparative Analysis of Differentiating Features
If a feature is present (or absent) in only one or two implementations,
then the "yes" or "no" is upper cased for emphasis.
Feature \ Package #
| 1
| 2
| 3
| 4
| 5
| 6
|
shell script app
| YES
| no
| no
| no
| no
| no
|
Scheme app
| YES
| no
| no
| no
| no
| no
|
config file input
| yes
| no
| no
| yes
| no
| yes
|
environment input
| YES
| no
| no
| no
| no
| no
|
config file output
| YES
| no
| no
| no
| no
| no
|
callback functions
| yes
| NO
| yes
| yes
| yes
| NO
|
multiple occurrence
| YES
| YES
| no
| no
| no
| no
|
parameter types
| [1]
| 4
| 5
| 5
| 11
| 4
|
enumeration opts
| YES
| no
| no
| no
| no
| no
|
optional argument
| YES
| YES
| no
| no
| no
| no
|
default values
| yes
| yes
| yes
| yes
| NO
| yes
|
range checks
| yes
| yes
| yes
| no
| no
| no
|
consistency checks
| YES
| no
| no
| no
| no
| no
|
standard opts
| YES
| no
| no
| no
| no
| no
|
man page
| YES
| YES
| no
| no
| no
| no
|
texinfo invoking
| YES
| no
| no
| no
| no
| no
|
developer dependencies
| Guile
| tcl
| none
| none
| none
| bison,flex
|
user dependencies
| [2]
| none
| none
| none
| none
| none
|
"multiple occurrence" options may appear multiple times on the command line.
Some of the parsers constrain options to appearing once only.
"optional argument" refers to the argument to an option.
POSIX and most command line parsers require an option to either not have
an argument or else the argument must be supplied on the command line.
GNU's getopt_long and some of these parsers support the notion of
letting the option argument be "optional".
"consistency checks" verify that conflicting options do not appear
together, and options that require other options are allowed only
if those other options are present.
"standard options" are pre-defined options that can be trivially
incorporated into a user's set of options. They can also thereby
be used for standardizing on the flag character and option name.
[1] See the list of features, section Option Argument Specification.
[2] There is a user-visible dependency iff the developer does a
dynamic link to the libopts.so library. Developers are free
to either link statically or ship libopts.so with their product.
A Debian package would need only a dependency on the package
supplying libopts (libopts11, at present).
The Guile library is now generally pre-installed on all
GNU/Linux systems.
-- James R. Van Zandt
-- Bruce Korb
Go to the first, previous, next, last section, table of contents.