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 Message-ID: <2392@ut-sally.UUCP> Date: Thu, 18-Jul-85 11:53:58 EDT Article-I.D.: ut-sally.2392 Posted: Thu Jul 18 11:53:58 1985 Date-Received: Fri, 19-Jul-85 03:29:08 EDT References: <251@mcc-db.UUCP> <2365@ut-sally.UUCP> Reply-To: std-unix@ut-sally Organization: U. Texas CS Dept., Austin, Texas Lines: 179 Approved: jsq@ut-sally.UUCP From: John Quarterman (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@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@mcc-db.UUCP> Organization: AT&T-IS Labs, Lincroft, NJ In article <250@mcc-db.UUCP> you write: >Date: Thu, 11 Jul 85 14:07:41 EDT >From: Keith Bostic >Subject: getopt(3) (again...) > >Just when I thought it was safe to read my mail... > >> From: harvard!talcott!wjh12!mirror!rs@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 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@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@ut-sally.ARPA Comments to: ut-sally!std-unix-request or std-unix-request@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@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDU