Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP Path: utzoo!decvax!genrad!panda!talcott!harvard!seismo!ut-sally!jsq From: jsq@ut-sally.UUCP (John Quarterman) Newsgroups: mod.std.unix Subject: Re: a bit more on getopt (retransmitted) Message-ID: <2445@ut-sally.UUCP> Date: Tue, 23-Jul-85 13:41:46 EDT Article-I.D.: ut-sally.2445 Posted: Tue Jul 23 13:41:46 1985 Date-Received: Wed, 24-Jul-85 01:41:12 EDT References: <251@mcc-db.UUCP> <2365@ut-sally.UUCP> <2392@ut-sally.UUCP> <2401@ut-sally.UUCP> <2409@ut-sally.UUCP> Reply-To: std-unix@ut-sally.UUCP Organization: U. Texas CS Dept., Austin, Texas Lines: 220 Approved: jsq@ut-sally.UUCP From: John Quarterman (moderator) 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@mcc-db.UUCP> <2365@ut-sally.UUCP> <2392@ut-sally.UUCP>, <2399@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@ut-sally.ARPA Comments-To: ut-sally!std-unix-request or std-unix-request@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)