Hi!

From the feedback it seems that the new getopt behaviour is not
wanted.

I'll change the default (to not swap arguments and stop option parsing
at the first non-option argument) before doing the change I proposed.

Is it okay if getopt reacts to an environment variable like
"GETOPT_SWAP_ARGS" (better names are appreciated) for the users who
want to have the new functionality? (If not, please argue the point --
I'd try to fix all in-tree programs to work with both behaviours, of
course.)

Some replies:

Chris G. Demetriou wrote:
> Uh, as far as I know and am concerned, that is _not_ the correct
> behaviour for most programs.
> 
> for instance, the syntax for 'cat' is:
> 
>      cat [-benstuv] [-] [file ...]
> 
> and that's as it has historically been (modulo additional options,
> etc.)
> 
> If you specify a file name, that is the end of option parsing, period.
> 
> I don't think the new behaviour you describe should be the default for
> _any_ existing program in our source tree, unless you can provide some
> documentation (e.g. a standard like POSIX.2 or one of the X/Open ones)
> that mandates it.

I can't. I found it a nice feature if getopt does this, but it seems
nobody else does. (Except on Linux, where this behaviour is the
default -- yes, that's their problem, I know).

Todd Vierling wrote:
> A getopt(3) replacement MUST function IDENTICALLY to getopt(3) as it has
> been in libc with option strings that already exist.  No exceptions; this is
> ABI compatibility.

I don't really get this argument -- doesn't it sometimes happen that a
libc change mandates that some userland programs have to be recompiled
(perhaps with a libc minor bump)? There are only a handful programs
that would have to be recompiled (see the patch, and perhaps some more
I hadn't thought of).

Jason R Thorpe wrote:
> On Wed, Nov 01, 2000 at 06:58:59PM -0800, Chris G. Demetriou wrote:
>  > I don't think the new behaviour you describe should be the default for
>  > _any_ existing program in our source tree, unless you can provide some
>  > documentation (e.g. a standard like POSIX.2 or one of the X/Open ones)
>  > that mandates it.
> 
> Agreed -- and, in fact, it would break some programs either in the
> tree now, or hitting the tree soon.
> 
> There *ARE* programs out there that do:
> 
> 	foo -b foocmd -cd
> 
> i.e. -cd are flags to foocmd, not foo.

Yes, but that could easily be fixed by adding '+' as the first
character to the options string. And I'd have fixed the in-tree
programs for this, of course.

Bye,
 Thomas

-- 
Thomas Klausner - wiz@danbala.tuwien.ac.at
I think...I think it's in my basement. Let me go upstairs and check.
 -- M.C. Escher (1898-1972)