Xref: utzoo comp.lang.c:8714 comp.unix.wizards:7477
Path: utzoo!mnetor!uunet!tektronix!reed!percival!littlei!ogcvax!schaefer
From: schaefer@ogcvax.UUCP (Barton E. Schaefer)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: command line options
Message-ID: <1604@ogcvax.UUCP>
Date: 29 Mar 88 17:53:02 GMT
References: <2414@zyx.UUCP> <srs.738>
Reply-To: schaefer@ogcvax.UUCP (Barton E. Schaefer)
Organization: Oregon Graduate Center, Beaverton, OR
Lines: 60

From article <2414@zyx.UUCP> aj@zyx.SE (Arndt Jonasson) is quoted:
} [Proposal for a more convenient way to parse command line options]
} ...a static option descriptor array is initialized at compile
} time and passed to the function 'O_parse_options' at runtime.
}
}Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden
}email address:	 aj@zyx.SE	or	<backbone>!mcvax!enea!zyx!aj

In article <srs.738> srs!dan@cs.rochester.edu (Dan Kegel) responds:
} We like this idea, but we implemented it a little differently.
} The "Option descriptors" can be placed into a scanf-style string.
}     argproc(argc, argv, "=f -d%g -s%s %s %s", &flag, &dbl, string, 
} 	arg1, arg2);
} The format string to argproc contains flag names (-d, -s) optionally followed
} by value type specifiers a la scanf (%g %s).  If the flag name is introduced
} by '=' instead of '-', a boolean variable in the argument list is set TRUE
} or FALSE according to whether the flag was given or not.
} -- 
}   Dan Kegel   "... earn it anew if thou wouldst possess it."  - Goethe: Faust
}   srs!dan@cs.rochester.edu  rochester!srs!dan dan%srs.uucp@harvard.harvard.edu

I like the second idea better than the first because no static/global storage
is required; it's more modular.  However, both seem to have (fixable)
drawbacks.  Arndt's option parser, as I recall (I don't have the original
article here), returns "a pointer to the first non-option argument"; this
seems to imply that all options must precede any non-option arguments on the
command line.  I'd prefer to be able to mix them arbitrarily (with obvious
restrictions, e.g., if "-f" is used to introduce a file name, then that file
name must immediately follow the option, if "--" appears then none of the
remaining arguments are treated as options, etc.).  I can't tell from the brief
description given whether Dan's function can handle this or not, but I'll give
the benefit of the doubt.

The problem with Dan's function is that it appears to have no provision for
parsing an arbitrary number of arguments (e.g., "rm" can take as many file
names as the shell can handle in one command line).  I therefore make the
following suggestions:
    1)  Change the first argument of argproc to (int *) and return the
	number of arguments remaining after processing by storing through
	this pointer.  It would normally be passed &argc as the first
	argument.
    2)  Allow argproc to rearrange the pointers in argv to move successfully
	processed arguments to the front of the array.  THIS DOES NOT MEAN
	COPYING THE ARGUMENT STRINGS.  I know what kind of chaos could result
	if argv[5], "antidisestablishmentarianism", were copied to argv[2],
	which might be "the".
    3)  Make the return value of argproc be of type (char **), a pointer to
	the first not-yet-processed argument.  The rearranging in (2) will
	ensure that all unprocessed arguments are grouped in the last argc
	positions of argv, where argc has the value returned in (1).  This
	allows successive calls to argproc to parse a long argv.

Comments?  Arguments (no pun intended :-) against doing (2), which is the
most questionable step?  Random flames? ....

-- 
Bart Schaefer			CSNET:	schaefer@cse.ogc.edu
				UUCP:	...{tektronix,verdix}!ogcvax!schaefer
"You can lead a yak to water, but you can't teach an old dog to make a silk
purse out of a pig in a poke."			-- Opus