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