Xref: utzoo comp.lang.c:9124 comp.unix.wizards:7686
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!think!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.lang.c,comp.unix.wizards
Subject: Re: command line options
Message-ID: <48981@sun.uucp>
Date: 10 Apr 88 20:16:11 GMT
References: <2414@zyx.UUCP> <8039@elsie.UUCP> <7628@brl-smoke.ARPA> <143@gsg.UUCP> <7641@brl-smoke.ARPA>
Sender: news@sun.uucp
Followup-To: comp.unix.wizards
Lines: 27

> The particular usage message produced depends entirely on what the
> implementor of the application decided was the appropriate response
> to an illegal option.

The usage message might very well be "bad syntax".  I don't think this is a
*good* usage message, but the point is that you're not *guaranteed* to get a
usage message from '-?'.  You may be *likely* to get one, but you're certainly
not guaranteed to get one.

The *only* thing that sets '-?' apart from any other convention is that
"getopt()" returns '?' when it sees a syntax error.  Were it not for the fact
that "?" is a shell meta-character, this would give this convention a leg up as
you don't have to put in any additional code to recognize "-?".  However, each
individual implementor still has to put in code to do something useful with
this option.

Yes, doing so is a good idea.  So is using "perror" or "sys_errlist[]" to print
error messages, and *that* idea seems to be ignored by all too many UNIX
utilities.  Just saying that implementers *should* do something does not mean
that they will.

> My point is that there is already the necessary hook for this under
> the present getopt() scheme; nothing needs to be changed to use it.

Other than user's habits; they have to remember to quote the '-?' any time
there is any chance that it *might* expand to something.  As Arthur Olson
pointed out, this is *not* a hypothetical situation.