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

Well, it seems I may have been hasty to state that.  More follows.

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

Date: Tue, 16 Jul 85 19:10:43 edt
From: ihnp4!cmcl2!edler (Jan Edler)
To: ihnp4!ut-sally!std-unix
Subject: another getopt

Another important public-domain implementation of getopt(3)
is the one from AT&T available from the UNIX system toolchest.

	Jan Edler
	New York University
	ihnp4!cmcl2!edler
	edler at nyu.arpa

[ The toolchest number is 201-522-6900, where you can log in as guest.
Getopt is listed as for $0.00, though there is evidently a $100.00
registration fee, a transfer fee ($10?) and tax.

If the source for this was actually published in the Dallas /usr/group
meeting proceedings, could someone who has them please type it in and
submit it to this newsgroup?  I could assume that the getopt in my
System V sources is the same as that published at Dallas and post it,
but it might not be.  -mod ]

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

From: seismo!cbosgd!pegasus!hansen (Tony Hansen)
Date: Thu, 18 Jul 85 01:29:42 EDT
To: ut-sally!std-unix, cbosgd!seismo!keith
Subject: Re: getopt(3) (again...)
In-Reply-To: <250 at mcc-db.UUCP>
Organization: AT&T-IS Labs, Lincroft, NJ

In article <250 at mcc-db.UUCP> you write:
>Date: Thu, 11 Jul 85 14:07:41 EDT
>From: Keith Bostic <keith at seismo.CSS.GOV>
>Subject: getopt(3) (again...)
>
>Just when I thought it was safe to read my mail...
>
>> From: harvard!talcott!wjh12!mirror!rs at ut-sally.ARPA (Rich Salz)
>>
>> i made a couple of changes.  esthetics, absolutely no stdio if
>> desired, and the opterr variable.  here's my revision:
>
>I'm getting pretty tired of this whole issue -- in fact, I kept starting
>to reply to your mail and then deciding not to, figuring that if I didn't
>maybe the whole thing would die off.  *sigh*  Well, my friend, here's
>a reply.  The content is simple.  You are wrong.  Pure-d, absolutely,
>wrong.

Actually, the recently posted rewrite by Rich Salz is closer to AT&T's code
than is yours and his is more accurate.

>Point by point:
>
    ... (no comment on aesthetics)
>
>absolutely no stdio if desired:
>	Well, for an error condition that's going to happen once before the
>program exits, it's gonna be faster.  You saved about 2 routine calls, near
>as I can figure.  You didn't save any library space, which is why I changed
>the original fprintf() calls to fputs() calls.

Actually this is important in some applications which do not already use
stdio and do not wish to load in the 10k or so overhead that using stdio
incurs. AT&T's code does not use stdio in getopt(3).

>the opterr variable:
>	The other two items, I could live with.  Here, on the other hand,
>you have single-handedly created a real pain in the ass in terms of
>portability.
>
>Scenario #1:
>	Bell Labs doesn't ever decide to use opterr.  Fine and dandy,
>	except that people who use your new flag will find that their
>	code will not run as expected on USG UNIX.

Sigh. Here's the real crux of the matter: USG UNIX already has and uses
opterr exactly as used by Rich's code. It is poorly documented,
unfortunately.

>I would have been much more amenable to changes two months ago; if you
>can get Mike Karels to use your version rather than mine, I will again
>be much more amenable to changes.  Well, with the exception of your use
>of opterr.

I thought UCB had a System V license. Couldn't they have checked your
public-domain version against the code that was in the System V source
easily enough for incompatibilities?

In fact, why go with yours or Rich's version at all and not use the
public-domain version that AT&T published at January's Uni-Forum in Dallas?
That would have gotten rid of all thought of incompatiblity!
[ They may not have been aware of it:  few other people seem to be.
Perhaps you could type it in and submit it to the newsgroup? -mod ]

>  The world does not need another getopt.

You're right. Why'd you bother adding one? :-)

>	..., or, of course, we could just diverge the two systems
>	again.  Fun, fun!

I hope 4.3BSD picks up AT&T's public-domain version of getopt(3) for use
rather than creating yet-another branching of ways by using yours, Keith, or
Rich's.  [ You could submit the AT&T source to Berkeley as a bug fix.  -mod ]

					Tony Hansen
					ihnp4!pegasus!hansen

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

From: Dave Berry <seismo!cstvax.ed.ac.uk!mcvax!db>
Date: Tue, 16 Jul 85 15:43:56 bst
To: ut-sally!std-unix
Subject: Command lines

It's probably way too late for this to be suggested, but the longer it's
left, the worse it will be.
How about completely revamping the unix command line syntax to be
	command {{-option ...} {file ...} ...}
with command names & option names being full words (e.g. remove, not rm)
and using command (and argument) completion a la VMS?  I used UNIX for three
years before using VMS, and I far prefer this approach to command line syntax
(though VMS filenames & DCL are appalling!).
	A couple of MMI articles I've read (in CACM I think) report evidence
that users far prefer command completion to cryptic abbreviations in the
UNIX tradition.
	The rest of UNIX is being dragged kicking & screaming into the
"real world" - I'd like to see this change happen too.

[ Command and file name completion has been added to the C shell in
several steps and posted to net.sources over the last couple of years.
4.3BSD will include both (made quite a bit more efficient) as an option
in the distributed C shell (according to what the Berkeley CSRG people
said at the 4BSD BOF at the Portland USENIX).  I don't know if such
has been done in any version of the Bourne or Korn shells.  -mod ]

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

From: jsq at ut-sally.ARPA (John Quarterman)
Date: Thu Jul 18 10:51:48 CDT 1985
To: ut-sally!std-unix
Subject: Re: Command lines

It seems to me that general command argument completion would have to
be implemented in each command, and would require each command to be
able to interact with terminals.  Doesn't seem worth it to me, but then
I've always thought argument completion to be one of TENEX/TOPS-20/VMS's
most annoying features.  Argument completion would also seem to rule
out multiple options in the same word, which is a bit of a compatibility
problem.

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

This moderated newsgroup, mod.std.unix, is for discussions of UNIX standards,
in particular of the draft standard in progress by the IEEE P1003 Committee.
The newsgroup is also gatewayed to an ARPA Internet mailing list.

Submissions to:	ut-sally!std-unix	  or std-unix at ut-sally.ARPA
Comments to:	ut-sally!std-unix-request or std-unix-request at ut-sally.ARPA
Permission to post to the newsgroup is assumed for mail to std-unix,
but not for mail to std-unix-request, 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