command line options

[Dan Kegel]

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().
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.

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.

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

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?
-- 
  Dan Kegel   "... earn it anew if thou wouldst possess it."  - Goethe: Faust
  srs!dan at cs.rochester.edu  rochester!srs!dan dan%srs.uucp at harvard.harvard.edu