[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140726174730.GA11205@euler>
Date: Sat, 26 Jul 2014 19:48:30 +0200
From: Felix Janda <felix.janda@...teo.de>
To: musl@...ts.openwall.com
Subject: Re: More GNU semantics for getopt_long?
Rich Felker wrote:
> On Sat, Jul 26, 2014 at 11:12:36AM +0200, Felix Janda wrote:
> > I have had two problems with the fact that musl's getopt_long() does
> > not behave as applications expect.
> >
> >
> > No argument reordering:
> >
> > musl's getopt_long() behaves similarly to POSIX getopt() and therefore
> > stops after the first non-option argument. This for example makes the
> > utilities widl and wrc from wine when compiled with musl libc behave
>
> This has been discussed a few times and could possibly be changed.
> Some consideration is needed for whether it leads to problematic
> inconsistency between getopt and getopt_long, but I don't think so.
> The worst part is that it makes it impossible to get conforming
> behavior from GNU coreutils since there would be no way to override
> the reordering (whereas, if they replace getopt_long with their own
> version, it can be overridden by setting the POSIXLY_CORRECT
> environment variable).
The BSDs seem to have this inconsistency between getopt and getopt_long
as well. Their getopt_long also respects POSIXLY_CORRECT, though. This
is IMO something musl should do as well when possibly introducing the
reordering of arguments in future.
> > differently than for everyone else. In particular, this breaks the
> > (git) wine build itself, since its generated Makefiles call widl with
> > mixed option and non-option arguments.
> >
> > Should wine use a (runtime) config test detecting whether
> > getopt_long() does argument reordering and use its internal copy of
> > getopt_long() if not? Should the Makefile generation be carefully
> > rewritten such that non-options are given last?
>
> I'm not a fan of the misordered options/non-option-arguments, so I'd
> recommend "fixing" that in the Makefile even if musl's behavior
> changes. Note that the build process probably breaks if the user has
> POSIXLY_CORRECT set in their environment since this turns off the GNU
> reordering in glibc.
Good, I have a patch for their Makefile generation. Thanks for
pointing out that the build should also break for others when
POSIXLY_CORRECT is set.
> > It seems difficult to upstream any of these. The config test
> > seems like a test specific to exclude musl and the second is
> > likely to break in the future and who knows what scripts might
> > depend on the argument reordering of widl.
> >
> >
> > No abbreviations:
>
> Oh, there was a patch submitted for this one, and I thought I
> remembered applying it, but perhaps not. I'll go back and look. There
> might have still been some open issues with it to be resolved before
> applying.
>
> > I noticed that there is a patch from Michael Forney on the mailing
> > list implementing the abbreviated options but there were not any
> > comments on it.
>
> Yes that's it.
Thanks for revisiting the patch.
Felix
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
