|
i |
|
Here is a feature comparison of AutoOpts and several other command line parser generators. All except argtable and argp share certain characteristics:
-
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.
argtable and argp create the option parsing information
by calling functions and initializing data structures, respectively.
The 9 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 ``getopt_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. opt is a subroutine library. Options are specified by calling
a registration routine in the library, instead of using a separate
option specification file. Global option state is stored in variables
passed by address to the registration routine. It has some strange
syntax for its own options: '@' says to read a config file, '$'
says to go into interactive mode. argtable is a little different from the others in that the
argument descriptor is built up dynamically with run time calls to
various constructor routines. There are eight argument descriptor
types (structure types) and three constructors for each type, plus
an ``end'' function.
Developers will need to incorporate the library into their distribution. wyg uses flex and bison to generate a configuration file
parser, but uses getopt_long to parse the command line options. argp is a tiny step above ``getopts_long(3GNU)''.
It handles looping over the command line arguments, but does not
handle the individual options. It calls a hand crafted callback
function that must do a ``switch'' on the option key (flag
character). The needed information is conveyed to the
``argp_parse'' function via a hand crafted complex data
structure.
If a feature is present (or absent) in only one or two implementations,
then the "yes" or "no" is emphasised.
- shell script app
- This parser will either produce a shell script to parse options, a
program that emits digested information as a list of environment
variable assignments, or both. AutoOpts will produce both.
- Perl app
- This particular parser is primarily designed for Perl applications.
- config file input
- Option settings can be obtained from one or more configuration files.
- config file output
- By specifying the "--save-opts" option, the option processing state
will be saved to either a named file, or to the last named search place
(highest priority initialization file).
- config file editor
- The option definition file may specify support for the "--reset-option" option with the resettable attribute. In conjunction with emitting a
configuration file, this enables a fully automated configuration file
editor with the output assured to pass option processing consistency
checks.
- config file library
- A separately callable interface is provided so programs may use the
config file parser code without having to also use the option processing
code.
- embedded options
- Option settings can be obtained from program input files.
When they are encountered, the text can be passed to a function
that will parse it and adjust the current option settings.
- environment input
- Option settings can be obtained from environment variables.
- immediate handling
- Sometimes it is necessary to handle options out of order.
For example, a command line option used to bypass initialization
files must be processed before processing initialization files.
Since command line options override initialization files, the
initialization files must be handled first. Option parsers that
have this "immediate handling" capability can process marked
options early.
- callback functions
- A means is provided for calling a user-supplied function when a
particular option is encountered.
- getopt-long
- Some developers are willing to forego some of the features of
AutoOpts in order to not have to futz with carrying a copy of
libopts with their project. AutoOpts can now generate an
option processing loop that uses getopt_long(3GNU) to parse
the options. Several other parsers require the library in order to
use it.
- multiple occurrence
- options may appear multiple times on the command line.
Some of the parsers constrain options to appearing once only.
- option arg types
- Some parsers have special treatment coded in for different types of
option arguments. "getopt", for example, treats them all as strings.
Others have a restricted list of handling methods. (Converting
integers to their binary values, for example.) AutoOpts supports several, and also makes it easy to roll your
own via an integrated callback procedures.
- enumeration opts
- A numeric value is specified by name. The values are set with
an enumeration.
- set membership opts
- A set of bits are turned on, turned off and tested by name.
- file name
- The directory portion of the name is validated for existence.
Existence or non-existence of the file may also be validated.
It may also be pre-opened during option processing.
- 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".
- standard opts
- 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.
This can also be viewed as a template for implementing project specific
standard options.
- library options
- Is there a means for handling options for library code without having
to manually incorporate them into a program's option processing code?
This is often handled by invoking additional parsers for unknown options.
AutoOpt-ed programs calling AutoOpt-ed libraries may combine their
option information automatically, yielding a very consistent ``look
and feel''. AutoOpt-ed programs and libraries may work with such code
by not error-failing on unknown options and instead performing the
necessary actions when such options are encountered. ``argp''
code only works with libraries that support argp argument handling
functions.
- range checks
- These parsers will (optionally) validate that integer option arguments
have a value that lies within a specified range. Some (e.g. AutoOpts) will allow for multiple ranges.
- 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.
- interactive
- means that the option processing package is able to
interactively query the user for option state.
- reset/restart
- means that you can save your current (possibly initial)
processing state and reprocess options. In this fashion, a daemon
process could reload its initialization (config) files.
- reordering
- Some traditional programs also require intermixed command line options
and operands. AutoOpts can move all the command options to the
beginning of the argument list and process them. NB: "reordering" is
implemented by getopt_long(3GNU), so it is automatically
incorporated into parsers that use that library function.
- main procedure
- AutoOpts will produce any of several main procedures, including versions for supporting shell scripts,
Guile-based utilities, mains that operate on either operand lists or
lists read from stdin, or even customized main procedures.
- man page
- The utility will take the argument description and produce a usable
"command and utility" man page.
- texinfo invoking
- The utility will take the argument description and produce a usable
"invoking" chapter or section for texinfo documentation.
- exit code enumeration
- The list of exit codes are enumerated for use by the C program and
inserted into the generated documentation.
- time duration
- The option argument may be a string specifying a time duration
that gets converted into a count of seconds.
- time and date
- The option argument may specify a time and date. It gets converted
into a count of seconds since the epoch, per the rules for
getdate(3posix).
- i18n support
- By compiling your code with ENABLE_NLS defined, you will
enable a translation function generated into your code. By providing
translations of the strings found in the distributed header file,
${prefix}/include/usage-txt.h, AutoOpts error messages and
usage text will be translated before processing begins.
- developer dependencies
- An application developer that uses the parsing tool must have the named
tool(s) at his disposal.
- user dependencies
- A user must either have the referenced C library installed, or else
the developer must ship a copy of the library with his application.
[1] Option argument handling is programmable.
Several kinds of argument attributes may be specified.
See the list of features, 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 ship libopts with their product in either source or binary form.
See the AutoOpts page for details on
the open-source licensing options.
A Debian package would need only a dependency on the package
supplying libopts (libopts-41, at present).
[3] opt supports a different argument
type for each fundamental type, plus booleans, inverted booleans, toggling
options and a couple others.
Also note that some of these parsers depend upon the GNU
getopt_long(3GNU) function. Those that do need to remember that it
is under the GNU LGPL license. Developers using the AutoOpts
command line parsing system may choose to use either the included
libopts library or getopt_long(3GNU) as the parsing engine.
-- James R. Van Zandt
-- Bruce Korb
|