Re: A plan for handling command line options

Richard Harter wrote:
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 specification.

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 code.

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 pathname.

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.


I examined the getopt() thing some time ago and rejected it as too complex. I have developed (or maybe copied) another scheme.

Assume a program called 'filt'. Called as 'filt --' we get help and usage information, at least..

Options: (may be combined)
-o odd
-p pairs
-t terns
-s short
Usage: filt [-opts ] [[ - | infile ] [ outfile ]]

The 'filt' defaults to its own options and to input from stdin and output to stdout. 'filt - outfile' takes its input from stdin.

It works for me..

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
.

Relevant Pages

  • TIP #185: Null Handling
    ... nulls, and command modifications for manipulating them. ... Tcl deals with strings, the universal medium for representing data. ... is know and it is an empty string, but if a respondent forgets to give ...
    (comp.lang.tcl)
  • Re: Determine how Word was launched
    ... inspect the command line used to launch Word. ... Private Declare Function GetCommandLineA Lib "kernel32" As Long ... Public Function GetCommandLineAs String ... Dim lngCmdLinePtr As Long ...
    (microsoft.public.office.developer.vba)
  • Re: Class.getMethod in classs static initializer block
    ... I just wanted to add that I had some similar code for a "command line server" project. ... static private final boolean DEBUG = true; ... {public ReturnCode runCommand(String s) ... public ReturnCode parseLine(String line) ...
    (comp.lang.java.programmer)
  • Re: New "base document" available
    ... How to go about retrieving command line parameters? ... the command line arguments (and environment variables) ... Keyword and positional parameters can be mixed in the same command line. ... clp-name points to a string containing "P1" ...
    (comp.lang.cobol)
  • Re: How about UserRPL command to store "bare" text to SD?
    ... just as with Kermit transfers. ... a string directly to the SD card, verbatim, ... whose function is simply "store this literal string to that file" ... a more basic and universal "store this literal string as a file" command. ...
    (comp.sys.hp48)