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: a bit more on getopt Message-ID: <2365@ut-sally.UUCP> Date: Tue, 16-Jul-85 15:35:20 EDT Article-I.D.: ut-sally.2365 Posted: Tue Jul 16 15:35:20 1985 Date-Received: Wed, 17-Jul-85 02:35:11 EDT References: <251@mcc-db.UUCP> Reply-To: std-unix@ut-sally Organization: U. Texas CS Dept., Austin, Texas Lines: 116 Keywords: option parsing, command line arguments Approved: jsq@ut-sally.UUCP Summary: we've pretty much covered this subject 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 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@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@ut-sally.UUCP>, <244@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@ut-sally.ARPA, soon to be jsq@sally.UTEXAS.EDU