Re: More GNU semantics for getopt_long?

[Felix Janda <felix.janda@posteo.de>]

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