"Greg A. Woods" wrote:

> >   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.

Personally, I'd as soon see misordered options banned,
but despite my opinion on that, there really is a critical
mass of GNU-ish coders out there who like the idea.  Consequently,
I allowed myself to be prodded into ``reorder-args''

  http://autogen.sourceforge.net/doc/autogen_191.html#SEC191

in my option processing toy.

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

Since it can be disabled with a '+' at the start of the option string,
you have to say "enhanced", even if we find it distasteful.

> 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.

Yeah.  The "enhancement" ought to have been a leading '+' meaning
"I am a traditional/grandfathered application that has options
appearing after operands.  Please reorder my arguments and I promise
my next incarnation won't require this."  :-)

> .... 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.

The current facts are that there is a critical mass of GNU applications
and GNU environments that want reordered arguments.  "ill-conceived"
"bad idea" -- there are all kinds of appropriate characterizations.
Nevertheless, reordered arguments are here to stay and it is pretty
pointless to argue that 20 years ago they had been banned.  Phoenix or
zombie, they are here.

Cheers -Bruce