a bit more on getopt

[John Quarterman]

From: John Quarterman <std-unix-request at ut-sally.UUCP> (moderator)
Topic: command line arguments (getopt)

There's getting to be a bit of repetition and a certain amount of
flamage on this subject.  Several things seem clear to me, at least:

1) Keith Bostic's getopt is the de facto standard public domain getopt
	because a) it implements everything the System V one does,
	down to specific error messages and global variables, and
	b) it's going to be in 4.3BSD.  It also may or may not be
	more efficient or smaller when seen in perspective.
2) Henry Spencer's getopt, in the version that I posted that Ian Darwin
	sent, is just about as good, since its earlier bug is fixed,
	though it lacks some undocumented System V features which
	Bostic's includes.
3) There are numerous minor functional changes which might be desirable
	for one reason or another, but they would *be* changes, and are
	not in the "standard" getopt.  The existing getopt is good
	enough for most purposes, and is widely available:  there is
	no need for another implementation.

While these are my personal opinions, they appear to agree with
those of the two getopt authors mentioned above.  Since I have
to go by something in moderating the newsgroup, I will discourage
from now on submissions which merely argue the above points again.
In other words, let's try to think of something new to say, or
go on to something else.


----------------------------------------------------------------------

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 15 Jul 85 16:10:12 CDT (Mon)
To: ihnp4!ut-sally!std-unix
Subject: Re: What to do about extraneous arguments?
References: <251 at mcc-db.UUCP>

> Common practice seems to be to ignore extraneous arguments.  A user here
> has requested that cmp(1) be modified to generate a diagnostic if more
> than 2 filenames are provided.  ...

The standard program skeleton for using getopt(3) includes, after the
big while-switch for the options, the code:

	if (errflg) {
		fprintf(stderr, "Usage: ...\n");
		exit(2);
	}

It's pretty simple to change that "if (errflg) {" to something like
"if (errflg || optind+2 != argc) {".  This is what we do in such cases.
Easy and effective.
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

------------------------------

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 15 Jul 85 16:09:35 CDT (Mon)
To: ihnp4!ut-sally!std-unix
Subject: Re: command line arguments
References: <2210 at ut-sally.UUCP>, <244 at mcc-db.UUCP>

> Regarding getopts and the 'all arguments are proceded by a "-"':
> What about arguments that can be on/off switches, or can be positive or
> negative numbers? In other words, what is wrong with allowing '+' as an
> indicator of arguments? There are some commands that use it already.

The AT&T people considered this.  (It would be nice to see a posting of
the AT&T paper, in fact, if someone has it machine-readable [I don't]
[ I don't either, but if someone would mail it to me, I would post it
(if it's reasonably short) -mod ]; it would shorten this discussion
considerably.)  They thought the following were reasonable criteria for
accepting + :

1. Clear, simple, well-defined rules for when + should be used.
2. Rules should be applicable to more than just a few atypical commands.
3. Use of + should complement, not conflict with, the general use of -
	as an option marker (*not* as a "negation" indicator, note).

Their observations were that the existing uses of + meet none of these
criteria, that compatibility would prevent cleaning up existing uses,
and that criterion #3 seemed impossible to satisfy.  So, no +.

> Incidently, what happens with getopts if the command line was
> command -n -30
> and:
> Option n is fetched
> option 3 is fetched
> option 0 is fetched
> 
> (No well written program would do all this, but essentially, what happens
> if an argument looks like a flag? Or have you never grep'ed for a string
> beginning with -?)

If -n is an option taking a value, then the next argument is its value,
even if it happens to have a - on the front.  The apparent ambiguity is
resolved by knowing which options take values and which don't.

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

----------------------------------------------------------------------

The moderated newsgroup mod.std.unix is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003
"UNIX Standards" Committee.

Submissions to the newsgroup to:	ut-sally!std-unix
Comments about the newsgroup to:	ut-sally!std-unix-request
Permission to post to the newsgroup is assumed for mail to the former address,
but not for mail to the latter address, nor for mail to my personal addresses.
-- 

John Quarterman,   UUCP:  {ihnp4,seismo,harvard,gatech}!ut-sally!jsq
ARPA Internet and CSNET:  jsq at ut-sally.ARPA, soon to be jsq at sally.UTEXAS.EDU