Xref: utzoo comp.unix.wizards:7549 comp.lang.c:8860
Path: utzoo!mnetor!uunet!husc6!cca!g-rh
From: g-rh@cca.CCA.COM (Richard Harter)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: command line options
Message-ID: <26574@cca.CCA.COM>
Date: 4 Apr 88 05:00:17 GMT
References: <2414@zyx.UUCP> <738@srs.UUCP> <26423@cca.CCA.COM> <761@srs.UUCP> <26550@cca.CCA.COM>
Reply-To: g-rh@CCA.CCA.COM.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge, MA
Lines: 42

Here are further issues for thought:

o	It is desirable that the argument processor be able to handle
	untokenized argument strings.  The reason for bringing this up
	is that our current processor can do this.  In applications with
	an interpretive command processor, the parser for the interpreter
	may not necessarily follow unix parsing command line parsing rules.

o	The objectives that I am concerned with are (a) functional extensions
	to the existing syntax [discussed previously], and (b) simplified
	usage.

The latter is worthy of some comment.  The getopt scheme typically involves
an arguments processing routine which calls getopt in a loop and then acts
on the option letter in a switch.  Each of these little suckers has to be
coded individually, even though they are all very similar.  Almost all of
the time the action is to set a flag or set a value.  If those are the only
actions being taken, the whole thing can and should be done in a standardized
routine.  Life (and maintenance) is a lot simpler that way.

This raises the question of what to do about special cases.  These fall into
two categories, conversions, and other.  The 'other' category is the user's
problem.  The consensus seems to be that the argument processor should have
the smarts to be able to do the conversions.  This is all very well, but my
concern is that this be done in a portable way that cannot crash.  What
happens if the string being converted to int contains garbage?  What had
better not happen is that routine crash.  Similarly, any system utilities
used should be generic -- available across a variety of operating systems
and not just flavor X of Unix.

o	When getopt processes an option with a value it returns a pointer
	to a location within a string that it is passed.  The assumption
	is made that this string is null terminated at the right place.
	No copy of the string is made.  My opinion is that the argument
	processor should generate a copy of the string or value.  This
	is relevant in the case of an interpretive command processor --
	the original token string may vanish.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.