command line options

[Henry Spencer]

> getopt also evolved out of a Bell Labs study by Hemenway and Armitage
> of the existing UNIX command options...

Actually, unless the H&A work dates back much farther than I'm aware of,
getopt pre-dates it.  H&A's syntax standard is tougher than getopt in
a number of places, most of which getopt can't really enforce, although
I believe one or two small tightenings of the getopt specs were planned
as a result.  Their recommendations turned out to match getopt fairly
closely.

> It was designed to be the best compromise common-ground facility

People who are gung-ho on new syntax standards should study the H&A work
first.  There are more issues than appear at first glance, and H&A spent
quite a bit of effort crafting the best compromise, and explaining *why*
the result came out the way it did.  You can find their paper in the
1984 UniForum Conference proceedings, which may still be available from
Usenix or /usr/group (that one was a joint conference).

> even though it was acknowledged that
> a totally different option syntax might be an improvement...

People who favor a radically new syntax, e.g. multi-character option names,
should consider one fact before investing much effort and shouting in
settling on a new syntax:  You Are Not The First To Try This.  Or the second.
Or the third.  All previous attempts have been failures, because the pressure
of backward compatibility and standardization is too strong.  Before tilting
at this windmill yet again, consider whether there is any reason why you
will succeed where others have failed.

The fact is that the existing syntax, warty though it is, works tolerably
well.  To get a new syntax accepted, it will have to be so much better that
it sells itself despite the compatibility issue.  Frankly, this isn't very
likely.
-- 
"Noalias must go.  This is           |  Henry Spencer @ U of Toronto Zoology
non-negotiable."  --DMR              | {allegra,ihnp4,decvax,utai}!utzoo!henry