Xref: utzoo comp.lang.c:8693 comp.unix.wizards:7468
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!ukma!uflorida!codas!usfvax2!pdn!tsc3b21!crash
From: crash@tsc3b21.UUCP (Frank "crash" Edwards)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: command line options
Message-ID: <257@tsc3b21.UUCP>
Date: 29 Mar 88 13:34:29 GMT
References: <2414@zyx.UUCP>
Organization: Transportation Systems Consulting, Inc, Palm Harbor FL
Lines: 99

From article <2414@zyx.UUCP>, by aj@zyx.UUCP (Arndt Jonasson):
> This is a suggestion for a command line parsing routine for C programs
> in Unix.
> 
> [ some stuff deleted. ]
>
> Does the ANSI C committee address this issue? Probably not, since
> argument parsing can be quite different on various operating systems.
> POSIX, perhaps?
> 
> [ some more stuff deleted. ]
> 
> Recently, I invented a parsing routine of my own that doesn't require
> the program logic to be supplied by the application programmer.
> Instead, a static option descriptor array is initialized at compile
> time and passed to the function 'O_parse_options' at runtime. Most
> programs won't need to access 'argc' and 'argv' at all (they have to
> be supplied to this function, of course). I post this in the hope of
> getting constructive comments on what features are missing in my
> scheme, and whether it is perhaps too restrictive or too general. If
> it seems to be generally useful, I will post the code to
> comp.unix.sources.
> 
> If successful, 'O_parse_options' returns a positive integer which is
> the index in argv of the first non-option argument (if none, it will
> point past the argument list). The application program can thus easily
> pick up the remaining arguments; that they are not too few or too many
> has already been checked.
> -- 
> Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden
> email address:	 aj@zyx.SE	or	<backbone>!mcvax!enea!zyx!aj

I have also written an implmentation of two routines used on, at least,
Revision 3 of the CRDS UNOS Operating System:  getargs() and getallargs().
(I don't know if these routines are intrinsic to UNOS or to the OEM
implmentation I was running.)

The call is similar, but a structure isn't required.  It goes something
like this:

main( argc, argv )
int argc;
char **argv;
{
    char *options = "h,help,b,bool,x#,file*";

    char *filename = NULL;
    int stat, help = 0, boolean = 0, debug = 0;

    stat = getargs(&argc, &argv, options,
	&help, &help,	/* First two options are mapped to a single variable */
	&boolean, &boolean,	/* as this one is, also. */
	&debug,		/* The 'x' option accepts a numeric count (default 1) */
	&filename);	/* Address of a char*; essentially copied from *argv */
    if (stat < 0 || help)
	usage( ... );
    .
    .
    .
    exit( 0 );
}

After the return from this call, "help" and "boolean" will contain
TRUE or FALSE, indicating that the corresponding option did or did not
appear on the command line, respectively.

Debug is the familiar "-xN" option specified as "x#" in the option
string.  If present on the command line, debug is set to one.  Then a
check is made for a numeric argument following.  If one is, it is
parsed (using strtol() -- any input base can be used) and stored in
debug.

And lastly, the char pointer from argv is copied to "filename" if
the "file" option is present.

Multi-character options options cannot be abbreviated by a single
letter unless the abbreviation explicitly appears in the option
string, i.e. "help" means the command line would have to contain
"-help" for the option to be recognized, whereas "h,help" would
allow either "-h" or "-help".  As in the example above, both options
would map to the same integer for simplicity.

------------

Well, I do tend to get a little long-winded at times.  But I find this
method very flexible and relatively easy to read while still hiding
the parsing of command lines in a library call.

There is a corresponding subroutine, getallargs(), which doesn't stop
at the first non-option command line argument, but continues to parse
all of the options on the command line.  Normally, getargs() returns
NULL and argc / argv are left pointing at the first argument that didn't
parse as an option.  So... the calling procedure can pick up right where
the getargs() call left off.

----
Frank (crash) Edwards		...!codas!usfvax2!{pdn,jc3b21}!tsc3b21!crash
TSC in Palm Harbor, FL		Phone:  (813) 785-0583  (voice)
The Sweat Shop			These opinions belong to no one.