command line options

[Henry Spencer]

> To be sure, 'getopt(3)' exists...  I find
> it a little bit too awkward to use, since I have to write a lot of
> code to interface to it (a loop with a case statement in it, usually).

There's an easy fix for this one, actually:  write that code once and
put it somewhere where you can get at it.  (See my paper "How To Steal
Code", given at the winter Usenix in Dallas.)  I agree it is a nuisance.

> ... [Do many people actually use [getopt]? I don't know.
> Most Unix tools don't seem to use it.]

A lot of new development uses it, but it is difficult to retrofit it into
many of the existing programs, because they often don't quite obey its
conventions and hence the retrofit could break things.  This would be a
problem with almost any option parser.  Actually, we've retrofitted getopt
into quite a few things (the greater consistency is a considerable win),
but there are programs that just don't fit its model.

> Does the ANSI C committee address this issue? Probably not, since
> argument parsing can be quite different on various operating systems.
> POSIX, perhaps?

This one seems to have fallen down the crack between them, actually.
It's definitely not in X3J11, and it wasn't in POSIX the last time I looked.

> Recently, I invented a parsing routine of my own...

Not a bad one.  One disadvantage, shared by many attempts to "pull things
together" more than getopt does, is that it does not permit arbitrary
actions for handling specific options.  The one thing getopt's loop-and-
switch really buys you is individual handling for each option, so you can
do things like range checks "on the spot".  How much this gets used, of
course, is another story...

One should also remember, for better or worse, that getopt is a de facto
standard.  (An official one, if you believe in the SVID.)
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {allegra,ihnp4,decvax,utai}!utzoo!henry