a bit more on getopt (retransmitted)

[John Quarterman]

From: John Quarterman (moderator) <std-unix-request at ut-sally>
Topic: command line arguments (getopt) (retransmission of earlier article)
	Is the AT&T getopt public domain, or just published?
	AT&T getopt(3) man page is inaccurate.
	Inclusion of stdio and size of programs.
	Options, white space, and shell scripts.
	Full word command names and arguments, and completion.

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 19 Jul 85 20:14:44 CDT (Fri)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Is AT&T getopt public-domain?  Not clear!

The document I have from the /usr/group standards meeting at Dallas
does *not* say that the AT&T getopt is being made public domain.  What
it says is:

	The [getopt] source code is being published by AT&T Bell
	Laboratories to encourage adherence to the command syntax
	standard and to satisfy requests from [everyone in sight].

Note that publishing something does *not* put it into the public domain
unless this is stated explicitly.  That may have been AT&T's intent, but
they didn't say it that way.  The document in question includes the AT&T
source, but I am reluctant to submit it to mod.std.unix until its status
is clarified.

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

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

Date: 20 Jul 85 11:03:28 EDT (Sat)
From: topaz!packard!nomad!ggr (Guy Riddle)
Subject: getopt: the Code vs. the Manual Page
To: ut-sally!std-unix
Cc: seismo!keith

I hope you haven't been modelling the 4.3 version of getopt(3) too
closely after the SVR2 manual page, for it lies about the details.

It states

	"Because optind is external, it is normally initialized to
	zero automatically before the first call to getopt."

Well, I'll grant that optind is external, but it is initialized to one.

Also, the claim that

	"This error message may be disabled by setting opterr
	to a non-zero value."

is also a lie.  Opterr is initialized to one, and to disable the error
message you must set it to zero.

		=== Guy Riddle == AT&T Bell Laboratories, New Jersey ===

----------
|Rebuttal
|Corner
|
	Keith's assertion that

	> Not true.  The size difference between:
	> 
	> 	main() { puts("foo"); }
	> and
	> 	main() { write(0,"foo",3); }
	> 
	> is exactly zero.

	might be valid for 4.2, but it's not for SVR2, where the size of the
	puts(3) version is

		2432 + 456 + 2232 = 5120

	while the write(2) version is only

		128 + 12 + 0 = 140

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

From: ihnp4!decvax!borman (Dave Borman)
Date: Sat, 20 Jul 85 21:01:42 edt
To: decvax!ihnp4!ut-sally!std-unix
Subject: getopt(3) & stdio

>  >  > 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).
>  > 
>  >  Not true.  The size difference between:
>  > 
>  >  	main() { puts("foo"); }
>  >  and
>  >  	main() { write(0,"foo",3); }
>  > 
>  >  is exactly zero.
>  
>  Your second one-liner is still using stdio.  The difference between
>     main() { puts("foo"); }
>  and
>     main() { write(1, "foo", 3); }   exit(n) { _exit(n); }
>  on the other hand, is substantial, at least on my 4.2 VAX system (and, in my
>  experience, on other UNIX systems as well):

The first two examples are different, the puts() will pull in stdio and
the write() should not.  If you have to explicitly re-declare exit() to
avoid pulling in the stdio package, then your /lib/libc.a is mucked up.
exit() calls _cleanup, of which there are two copies in the /lib/libc.a.
The stdio package has a function _cleanup which flushes all the buffers.
There is also a dummy _cleanup routine (usually fakcu.s) which just
returns.  In /lib/libc.a, exit() must be archived after all the stdio
functions, and the dummy _cleanup must be archived after exit.  If you
have exit() before the stdio functions, then the reference to _cleanup
will pull in the whole stdio package.  If exit() is after the stdio
package and the dummy _cleanup after exit(), then if you don't reference
any stdio functions you will only pull in the dummy cleanup routine.

		-Dave Borman, Digital UNIX Engineering Group.
		decvax!borman

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

Date: Sat, 20 Jul 85 16:31:33 PDT
From: seismo!sun!guy (Guy Harris)
To: ut-sally!jsq
Subject: Re: a bit more on getopt

> Not true.  The size difference between:
>
>	main() { puts("foo"); }
> and
>	main() { write(0,"foo",3); }
>
> is exactly zero.

Only true on certain UNIX implementations.  Under Sun UNIX 2.0
(4.2BSD-based), there is a slight difference.  Under System V there is a
significant difference.  The problem is that 4.2BSD *always* drags in the
Standard I/O Library while System V doesn't.  4.xBSD could be changed, with
about 30 minutes work, to work the way System V does here, so the assumption
should be made that the Standard I/O Library does consume a nonzero amount
of code and data space.  (About 13788 bytes in one test I did; this doesn't
count buffers which are "malloc"ed when the first read/write is done.)

	Guy Harris

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 20 Jul 85 20:45:50 CDT (Sat)
To: ihnp4!seismo!ut-sally!std-unix
Subject: Re: a bit more on getopt
References: <251 at mcc-db.UUCP> <2365 at ut-sally.UUCP> <2392 at ut-sally.UUCP>, <2399 at ut-sally.UUCP>

> > ...  The "-t/dev/tty" example is an easy one
> > to pick out, but what about "-dfaglop"?  Which of those letters are
> > options, and which are an option argument?
> 
> OK, instead of forcing whitespace, how about requiring that there only be one
> flag if you are going to do this sort of stuff? I have had shell scripts
> totally broken by this requirement, and workarounds take up so much overhead
> (yes, some people have systems smaller than vaxen) that it's not worth the
> hassle.

We do a *lot* of shell programming, and our experience is that the
separating blank makes life easier, not harder.  Of course, we generally
use getopt(1) for the argument parsing, which makes life simpler.  utzoo
is a PDP11, by the way.

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

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

From: ihnp4!utzoo!henry (Henry Spencer)
Date: 19 Jul 85 20:15:23 CDT (Fri)
To: ihnp4!seismo!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)...

The AT&T command-line-syntax people have alluded to attempts to do this
in the past at AT&T.  They were failures.  It is not enough to decree a
standard; one must also convince people to accept it.  The getopt standard
has been widely accepted precisely *because* it tidies up and standardizes
the existing situation, rather than trying to impose radical change.

There are also problems with full-word options, and worse problems with
full-word options that can be arbitrarily abbreviated, but I won't get
into that since it seems a digression.

I've thought about this at considerable length, and concluded that radical
change will require more incentive than a simplistic revision of command
syntax would provide.  VMS-style "completion" isn't enough.  What one wants
is much more sophisticated help in command construction, including things
like interactive "help" information for options, knowledge of the semantics
of arguments so that error repair can be applied, etc.  Imbedding this into
every program seems dubious; it would seem better to have a sophisticated
shell which uses a database describing the commands.  Note that such an
interface could completely hide the details of the *actual* command syntax.
Someday...
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry

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

Discussions-Of: UNIX standards, particularly the IEEE P1003 draft standard.
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
UUCP-Routes: {ihnp4,seismo,harvard,gatech}!ut-sally!std-unix
Archives-In: ~ftp/pub/mod.std.unix on ut-sally.ARPA (soon sally.UTEXAS.EDU)