Subject: Re: Switching from old-style getopt to new-style one
To: Thomas Klausner <firstname.lastname@example.org>
From: Greywolf <email@example.com>
Date: 11/03/2000 14:28:40
On Fri, 3 Nov 2000, Thomas Klausner wrote:
# >From the feedback it seems that the new getopt behaviour is not
# 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
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
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
# 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
# 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_.
*BSD: u_long uptime;