Subject: Re: Switching from old-style getopt to new-style one
To: Chris G. Demetriou <email@example.com>
From: Thomas Klausner <firstname.lastname@example.org>
Date: 11/03/2000 20:48:07
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
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,
> 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.
Thomas Klausner - email@example.com
I think...I think it's in my basement. Let me go upstairs and check.
-- M.C. Escher (1898-1972)