command line options

[Richard Harter]

I've put comp.lang.c back in, because that's where I've been following
the topic.  I don't follow comp.unix.wizards regularly, but I will pick
it up for the duration of the discussion.

In article <761 at srs.UUCP> srs!dan at cs.rochester.edu (Dan Kegel) writes:
]We've recently been mulling over what would be better than getopt().

]aj at zyx.SE (Arndt Jonasson) started the discussion by describing his
]static-structure-style argument processor.

]I posted a description of a scanf-style argument processor, argproc().
]Many people requested that I post argproc().  I'm ready to do so,
]but am still cleaning up the documentation.  

]Richard Harter (g-rh at cca.cca.com) posted a thoughtful list of desired
]features, which deserve discussion.  I agree strongly that, for most programs,
]o Long option names are a must.
]o The argument processor should handle ASCII-to-whatever conversion, 
]  preferably with sscanf().
	What we use currently is a character translation array.  In the
current implementation this is passed as a global, but it could (and
probably should) be passed as an argument.  At this writing, my opinion
is that this is better; it seems cleaner, it avoids sscanf (which I would
prefer to avoid on various grounds), and it separates character translation
from string interpretation.

]o Options should be freely intermixable with other arguments.
]o Non-switch positional arguments should be allowed.
]o The caller should be able to step through the list of arguments which
]  were ignored by the argument processor.
]Getopt() fails the first three.

	Agreed.

]I also agree that some programs (e.g. command-line interpreters) want to
]be able to call the argument processor repeatedly with different parameter
]vectors.  This implies
]o The argument processor shouldn't use any static or global variables
]o It should allow the caller to do as much of the error handling as desired.
]Getopt() fails both times.

	Since we (SMDS) have a product that incorporates a command-line
interpreter this is a live issue.  We strongly want to be able to use the
same option processing both in invoking the software and while running the
software.

	Error handling is an unresolved issue.  To put it politely, I
don't much care for the getopt approach to error handling.  Here are some
of the issues that I see:

o	The argument processor should be a one call routine, a contrasted
	to getopt, which is called once for each argument.

o	The error(s) should be returned.  An issue is whether the argument
	processor should process until an error is found and stop or whether
	it should keep going.  If if keeps going, should the error return
	mechanism specify all errors or just the first.  How should this be
	done?

o	If there is an error, should there be a partial setting of options
	or should options be set only if processing is completely successful.
	We do the latter -- this seems safer.

o	However this raises another question.  Should the argument processor
	do string conversion?  The reason for raising this question is that
	is simple to pass back a pointer to a string; there are no type
	conversion issues.  It may be that it better to split the processing
	into three parts: extraction, error handling, and processing.

]I disagree with his proposals that
]o switches may be abbreviated or case insensitive
]o the argument processor let the caller specify callback functions

	I withdraw the suggestion that the caller be allowed to specify
processing functions -- this is beyond the scope of the argument processor.
Case insensitivity, if desired, can be handled at the translation level.
[This is actually important if you are dealing with operating systems which
are case insensitive.]

	I am not so sure that I want to yield on the issue of abbreviation.
This may be simply prejudice -- I've worked with command processors that
did it each way and I find that I much prefer abbreviation.  The argument
for abbreviation is that you have the full name for documentation and for
the uncertain, and the abbreviated name for routine use.  A lot of DEC
operating systems use abbreviation.  As I recall, so does IBM's CMS.  PRIMOS
usually provides two forms, a long form and a short form.

	A compromise is to let the caller supply alternatives to the 
argument processor.  This shifts the burden to the software writer, but
it does provide more flexibility and control.

]My dilemma is that argproc() doesn't allow optional spaces between switches
]and their arguments; i.e. it can't treat "-ofilename" and "-o filename"
]as equivalent.  Changing this would require throwing out one of argproc's
]nifty features: optional arguments to switches (i.e. "-x " or "-x3.5")

]What do y'all think?  Should I go for getopt() compatibility now,
]or just post argproc() as is?

	I think your current version shouldn't be the final version --
there are too many holes and unresolved issues.  However I do think that
you should post what you have now so that people can look at it and
think about it.  A program is, in many ways, a detailed spec.

-- 

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