A plan for handling command line options
- From: cri@xxxxxxxx (Richard Harter)
- Date: Wed, 16 Aug 2006 22:41:04 GMT
This is a request for comments on an option processing scheme.
In the C programming world there is a common utility called
getopt that is used for processing command line arguments. It is
not standardized (TTBOMK) either by implementation or by
The general idea is simple enough - the user provides an option
spec. In the original form this is a string of characters, where
each character is an option letter. Option letters that take
arguments are marked with a colon.
Getopt is meant to be used by calling it once for each command
line argument until the options are exhausted. It returns
the option letter/string and places the option value (if any) in
a global variable. (Don't bitch if your version doesn't work
like this. Like I say about standards ...) The user is expected
to handle the logic of handling each option in an iterative loop.
It happens that I don't like getopt. IMNSHO it's clumsy and
ugly. It imposes on the user the need to write a bunch of code
that, for the most part, could be canned and hidden in a utility.
Below I describe a take on how to handle command options. I've
done an implementation, albeit not an industrial grade
implementation yet. I would be interested in comments,
suggestions, or pointers to something similar in open source
The general idea is to call a definition routine for each type of
option. Here are prototypes for some option types:
void opt_define_string(char * key, char ** string, char *initval);
void opt_define_flag (char * key, BOOLEAN * flag);
void opt_define_file (char * key, FILE ** fptr, char *mode);
In each case the first argument is an option string and the
second is the address of the place where a value will be placed.
The third argument for opt_define_string is the the default value
for the string being set, and the third argument for opt_define_file
is the mode string used to open the file.
In the command line a "string" type option will be followed by a
string value; a "file" type option will be followed by a
With the user program the command line arguments are processed by
a single call to routine optproc. The prototype is:
char ** optproc(int argc, char ** argv);
Optproc scans the argv vector, processes each command line
option, and returns the remaining non-option arguments.
There are two other option types that I am considering
implementing, function calls and numbers. For function calls the
definition would specify the function pointer and the number of
arguments; in the command line the option would be followed by
the appropriate number of arguments as strings. For numbers the
address argument would be the address of the number to be set.
An elaboration here is that the definition could contain the
numeric type (int, long, double, et al).
One issue is to decide how to handle files. In the current
implementation files with mode "r" are defaulted to stdin and
files with mode "w" are defaulted to stdout. For all other modes
the file pointer is defaulted to null. Then there is the
question of who is responsible for closing the opened files.
Another issue is error handling. There are several kinds of
errors to consider. There are various formatting errors. It may
not be possible to open a particular file. One approach to error
handling is to set errno and abort - this is plausible since the
program is still being initialized. Another approach is to
provide an error handling interface that the user can access.
Any thoughts or comments will be appreciated.