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: <2399@ut-sally.UUCP> Date: Thu, 18-Jul-85 18:48:44 EDT Article-I.D.: ut-sally.2399 Posted: Thu Jul 18 18:48:44 1985 Date-Received: Fri, 19-Jul-85 20:13:05 EDT References: <251@mcc-db.UUCP> <2365@ut-sally.UUCP> <2392@ut-sally.UUCP> Reply-To: std-unix@ut-sally Organization: U. Texas CS Dept., Austin, Texas Lines: 82 Approved: jsq@ut-sally.UUCP From: John Quarterman (moderator) Topic: still more on command line arguments (getopt) ---------------------------------------------------------------------- From: seismo!nsc!idi!bene!luke!itkin (Steven List) Date: Thu, 18 Jul 85 09:20:51 pdt To: ut-sally.ARPA!std-unix Subject: extraneous arguments Organization: Benetics Corp, Mt. View, CA >From: ihnp4!tektronix!uucp@ut-sally.ARPA >Date: Saturday, 13 Jul 85 18:43:47 PDT >Subject: What to do about extraneous arguments? > >Another aspect of command arguments is: after all the necessary arguments >have been processed, what if some are left? > I'm in agreement with tektronix!rdoty. I believe no program should produce unexpected results without some explanation. In the case of programs like cmp and diff, a diagnostic AND a nonzero exit status would seem to be appropriate. The diagnostic message would tend to satisfy checks on the size of the output being nonzero, and the status would satisfy status checks. ---------------------------------------------------------------------- Date: Wed, 17 Jul 85 12:00:54 cdt From: neuro1!baylor!peter@rice.uucp (Peter da Silva) Subject: Re: Re: command line arguments References: <245@mcc-db.UUCP> > Date: Mon, 8 Jul 85 00:52:46 pdt > From: nsc!turtlevax!ken@ihnp4.UUCP (Ken Turkowski) > Subject: Re: command line arguments > > Someone suggested that parsing arguments in shell scripts was difficult. > I include the following shell scripts, one for the Bourne shell and one > for the C-shell, which parse arguments of the form: > -v -O -o outfile file1 file2 file3 > as well as > -vOooutfile file1 file2 file3 > Sure, you can make shell scripts do almost anything. When I get a source with that sort of stuff in it I generally rip it out & put up with weirdness. Why? Well, our system is badly overloaded. Commands like that take 30 seconds to a minute to start up! ---------------------------------------------------------------------- Date: Wed, 17 Jul 85 12:04:53 cdt From: neuro1!baylor!peter@rice.uucp (Peter da Silva) Subject: Re: Re: command line arguments References: <246@mcc-db.UUCP> > > I doubt the necessity and even the wisdom of seperating an argument from > > the option by whitespace. > > As I recall it, the AT&T standard does it this way on the grounds of > readability, not necessity. 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. ---------------------------------------------------------------------- This moderated newsgroup, mod.std.unix, and the corresponding ARPA Internet mailing list, is for discussions of UNIX standards; specifically the draft standard in progress by the IEEE P1003 Committee. 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 -- 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