Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 exptools; site whuxl.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!whuxl!mike From: mike@whuxl.UUCP (BALDWIN) Newsgroups: net.unix Subject: Re: getopt(3) posting FLAME Message-ID: <744@whuxl.UUCP> Date: Sat, 26-Oct-85 13:21:33 EST Article-I.D.: whuxl.744 Posted: Sat Oct 26 13:21:33 1985 Date-Received: Mon, 28-Oct-85 03:24:50 EST References: <910@utcs.uucp> <306@graffiti.UUCP> <898@burl.UUCP> Organization: AT&T Bell Laboratories, Whippany Lines: 27 > > Incidentally, I strongly object to both the eventual enforcement > > of rule 6 in getopt(3c), > > What is rule 6? Hello Peter, did you read your followups in net.sources.bugs? AGAIN, here is Rule 6 of the Proposed Syntax Standard for UNIX System Commands: The first option-argument following an option must be preceded by white space. Now, is this clear? This means that if you have -o with an argument, say foo, you have to have a space between -o and foo. Also, Rule 5 says that options with no arguments can be grouped together, implying that options *with* arguments have to stand alone. Now, using this Proposed Syntax, you'd have to say "sort -bf -t x" instead of "sort -bftx". But now READ CAREFULLY: THIS IS THE PROPOSED SYNTAX, NOT THE CURRENT BEHAVIOUR OF GETOPT(3C). Getopt(3C) does *NOT* currently enforce Rule 6 or the strict Rule 5, so "sort -bftx" works with getopt(3C). It has been threatened that getopt will enforce these eventually, but I strongly disagree with that action. It should be left the way it is, but the documentation needs to be cleaned up (optind and opterr are documented wrong, and optopt isn't documented [why is it an int and not a char?]). -- Michael Baldwin {at&t}!whuxl!mike