On Fri, 3 Nov 2000, Thomas Klausner wrote:

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

FWIW, I think you're probably expending more effort than it's worth
to adapt to this new syntax.  I hate to seem a curmudgeon about this,
but I'm going to, anyway:  What we have isn't broken -- don't fix it.

At the best, to undertake this endeavour, I will call you "brave".

The new behaviour at all would violate the principle of least surprise.

I had realised that even tar, with all its options, follows the old
protocol of

	command -flags -opt0 optarg0 --lopt1 loptarg1 file ...

and options are not processed after the first non-option arg.

I have enough recollections of a file sitting around named "-C" to
have burned that rule into my brain.

# Some replies:
# 
# 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.
# 
# 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).

The key word there is "problem".  Linux is as bad as Microsoft in their
cavalier attitude that they think they can just rewrite the world to their
own standards.

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

The kind of changes that warrant bumping the minor number are usually
functional.

# Jason R Thorpe wrote:
#
# > 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.

But what's this gain?  It seems to be adding unnecessary complication
to a routine that already works _fine_.

				--*greywolf;
--
*BSD: u_long uptime;