Xref: utzoo comp.lang.c:9596 comp.unix.wizards:7999
Path: utzoo!mnetor!uunet!husc6!mailrus!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: command line options
Message-ID: <7753@brl-smoke.ARPA>
Date: 24 Apr 88 18:03:37 GMT
References: <2414@zyx.UUCP> <8039@elsie.UUCP> <7628@brl-smoke.ARPA> <143@gsg.UUCP> <4751@chinet.UUCP> <1073@mcgill-vision.UUCP> <283@fxgrp.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 44

In article <283@fxgrp.UUCP> ljz@fx.com (Lloyd Zusman) writes:
>Why is it that some of you are so fervently defending how '-?' is
>currently handled in getopt()?  Are you trying to imply that getopt()
>is perfect and nothing better can ever be invented, and that those who
>try to suggest that something better might be possible are worthy of
>nothing more than derision and scorn?  It sure seems that some of you
>feel this way.

Here's the situation as I see it.  Sure, any of a number of spiffy
argument parsing schemes can be designed.  I've seen several such
attempts, including one fairly good one contributed to a USENIX
tape several years ago by the company for which I worked at the time.
I don't think anybody has been arguing that getopt() could not be
improved upon.

When an effort was made in Bell Labs to consolidate the various
argument handling schemes, a study was made and the various
alternatives carefully considered.  It was decided at that time
that standardizing a la getopt() would be more widely useful than
any other alternative.  The command/option/argument syntax rules
were written, reviewed, and eventually adopted as an AT&T standard
(which several pre-existing UNIX utilities violated, of course).
The code necessary to implement this scheme was placed into the
public domain (the only instance I know of when this was done for
AT&T code), and the command syntax rules were incorporated into the
SVID.  Gradually, older utilities have been revised to follow the
new standard, which has several advantages over the ad hoc approach
typically seen in non-getopts()-using utilities.

The main advantage of getopt() is that it is HERE already, and it is
widely ACCEPTED.  I've been using it for years even though I could
invent a nominally superior technical solution.  The uniformity of
the option parsing rules has proven its value for me many times.

On the other hand, no "technically superior" design has received
widespread support.  You should feel free to try to change this,
but based on past experience I doubt that you will succeed.

As to "-?", I first raised that issue; it was intended to be an
observation that there is ALREADY a feature in many utilities
(those that use getopt() and have good usage messages) that can
exploited to get help.  I think it was misunderstood as an argument
that that would be the ideal way to get help in a totally different
design, which was never my contention.