Subject: Re: the state of getopt(3)...
To: None <bkorb@veritas.com>
From: Greg A. Woods <woods@planix.com>
List: tech-userlevel
Date: 10/01/2004 18:05:12
[ On Friday, October 1, 2004 at 12:29:18 (-0700), Bruce Korb wrote: ]
> Subject: Re: the state of regex(3)
>
> Before you start flinging too-short-in-the-tooth epithets, remember,
> please, the genesis of the problem:
> 
>   sort fumble -o stumble
> 
> et al.

That's _not_ the problem -- that's the _solution_!  :-)

>  Such requirements made the use of the getopt() function
> difficult/impossible.

Well, yeah.

The "--" option is a good idea, but for those who really do like mixing
option flags and parameters it could be said that it wasn't taken far
enough in terms of how getopt() actually works.


>  So, to enable utilities that allowed misordered
> options to use getopt(), getopt() was "enhanced" to make that
> sort invocation look like:
> 
>   sort -o stumble fumble
> 
> to the utility.

That's not getopt() that was enhanced -- it was more "de-enhanced".  :-)

Or rather the utilities were de-enhanced in order to allow them to use
getopt()...

What I meant by pointing out both V7 UNIX [which didn't have getopt()]
and the released version of AT&T getopt() was that we had this argument
well over two decades ago and getopt() won.  It wasn't a standards
issue, nor even an API issue, back then -- it was a basic question of
how command-line syntax should work and though we all may not agree on
the outcome, a consensus was reached and the "real" getopt() was only
released after the fact.

-- 
						Greg A. Woods
						Planix, Inc.

<woods@planix.com>     +1 416 489-5852 x122     http://www.planix.com/