Arg decoding with a template?

[Steve Holden]

"David Bolen" <db3l at fitlinxx.com> wrote in message
news:ulml5sz7m.fsf at ctwd0143.fitlinxx.com...
> Dale Strickland-Clark <dale at riverhall.NOSPAMco.uk> writes:
>
> > "Steve Holden" <sholden at holdenweb.com> wrote:
> >
Oh no I didn't. Which is to say, the message would make more sense with the
above attribution deleted, since all (now double-) quoted comments are
Dale's.

> > OK, I've had a good look at this now.
> >
> > It's hideous!
> >
> > It's no wonder that people get fed up with computers if they get
> > given a user interface that expects pointless dashes all over the
> > place.
> >
> > You simply can't use this routine to code a nice arg string.
>
> I suppose that's a matter of taste.  Certainly in the Unix domain,
> from whence this arose, where virtually everything was traditionally
> done via the command line, all command line utilities parse their
> command lines in exactly this way, it's extremely consistent and
> trying to do other manual approaches actually makes the non-conformant
> application stand out as such.
>
I got the impression that Dale was concerned his users wouldn't like the
Unix-like command lines that getopt requires.

> In effect, such command line parsing is a standard interface, much as
> under Windows, there's standard UI elements in its GUI.  It's also
> (unlike a GUI) designed as much for efficiency and flexibility as
> looks.
>
Yeah, well I'm sure nobody thought otherwise ;-)

> You'll find that it's a flexible interface for something that has to
> deal with a textual command line.  Try designing a CLI parser that has
> optional arguments, arguments with and without values even with
> multi-character options, spacing and order insensitive, and so on, and
> you'll find yourself replicating much of the getopt behavior.
>
> Personally, since DOS/Windows command line applications never really
> formed such consistency (IMO), and at least for me I find "-" less
> glaring on the command line than "/", I find the use of a getopt
> conformant command line to be nice as well as consistency
> cross-platform.
>
There is, of course, a history for both "-" and "/", and in point of fact
TOPS-10 was using "/" for command switches (as ISTR they were called) before
Unix was around. Wrote the command line processor for a TOPS-10 SPITBOL
compiler, and a switch with a value used a colon separator, as in

    sbl /code:sixbit myprog.sbl

and this usage was later extended to VMS, where it did sterling service for
years. It's all a matter of what you're used to, and getopt just proves that
people can get used to almost anything ... I suspect, without any evidence,
that CP/M, and later MSDOS, used the "\" as a path separator so they could
have hierarchical file stores and still use the "/" for switches (options).

> I don't know what particular user interface you are looking to serve,
> so if you're comparing this to some GUI interface to obtain
> parameters, that's not apples to apples.  But if you're working
> strictly with a command line, I wouldn't necessarily jettison getopt
> summarily.
>
I tend to use getopt because it's there, and it's easier than re-inventing
the command line processor.

but-that-doesn't-make-it-beautiful-ly y'rs  - steve
--
http://www.holdenweb.com/