getopt_long_only and slightly unambiguous options

getopt_long_only and slightly unambiguous options

[Felix Janda]

Hello,

since widl from wine uses the combination, get_opt_long_only seems to
be supposed to be able to differentiate between a short option "-h"
and a long option "--help". Together with the possibility of option
abbreviations, the behavior we are trying to copy is:

-h     -> -h
--help -> --help
-help  -> --help
-he    -> --help
--h    -> --help

However musl maps all of them to --help.

The man page is ambiguous about this aspect and I'm not sure if the
BSDs have the same behavior here. (However I would suspect that the
breakage in widl, when the --help option was added in 2012, would
have been noticed.) As always, it is hard to measure how many
applications (and scripts written against these applications) might
depend on this behavior. Since getopt_long_only is discouraged
maybe these are actually quite few, though.

All in all I think that this a bug in musl which should be fixed.


For the implementation, is it maybe enough in __getopt_long_core to
pass options starting with '-' and of exactly two characters
directly to getopt?

Thanks,
Felix

Re: getopt_long_only and slightly unambiguous options

[Rich Felker]

On Sun, Jan 18, 2015 at 06:51:59PM +0100, Felix Janda wrote:
> Hello,
> 
> since widl from wine uses the combination, get_opt_long_only seems to
> be supposed to be able to differentiate between a short option "-h"
> and a long option "--help". Together with the possibility of option
> abbreviations, the behavior we are trying to copy is:
> 
> -h     -> -h
> --help -> --help
> -help  -> --help
> -he    -> --help
> --h    -> --help
> 
> However musl maps all of them to --help.
> 
> The man page is ambiguous about this aspect and I'm not sure if the
> BSDs have the same behavior here. (However I would suspect that the
> breakage in widl, when the --help option was added in 2012, would
> have been noticed.) As always, it is hard to measure how many
> applications (and scripts written against these applications) might
> depend on this behavior. Since getopt_long_only is discouraged
> maybe these are actually quite few, though.
> 
> All in all I think that this a bug in musl which should be fixed.
> 
> 
> For the implementation, is it maybe enough in __getopt_long_core to
> pass options starting with '-' and of exactly two characters
> directly to getopt?

I would think getopt_long_only would even want to treat "-he" as "-h"
and "-e", i.e. abbreviations should be suppressed entirely when only a
single leading "-" appears instead of "--". However I'd rather follow
historical practice unless it's something stupid and complex (and
violating the principle of least surprise for users) like checking
whether each char is a valid short option and basing the decision on
that.

Rich

Re: getopt_long_only and slightly unambiguous options

[Felix Janda]

Rich Felker wrote:
> On Sun, Jan 18, 2015 at 06:51:59PM +0100, Felix Janda wrote:
> > Hello,
> > 
> > since widl from wine uses the combination, get_opt_long_only seems to
> > be supposed to be able to differentiate between a short option "-h"
> > and a long option "--help". Together with the possibility of option
> > abbreviations, the behavior we are trying to copy is:
> > 
> > -h     -> -h
> > --help -> --help
> > -help  -> --help
> > -he    -> --help
> > --h    -> --help
> > 
> > However musl maps all of them to --help.
> > 
> > The man page is ambiguous about this aspect and I'm not sure if the
> > BSDs have the same behavior here. (However I would suspect that the
> > breakage in widl, when the --help option was added in 2012, would
> > have been noticed.) As always, it is hard to measure how many
> > applications (and scripts written against these applications) might
> > depend on this behavior. Since getopt_long_only is discouraged
> > maybe these are actually quite few, though.
> > 
> > All in all I think that this a bug in musl which should be fixed.
> > 
> > 
> > For the implementation, is it maybe enough in __getopt_long_core to
> > pass options starting with '-' and of exactly two characters
> > directly to getopt?
> 
> I would think getopt_long_only would even want to treat "-he" as "-h"
> and "-e", i.e. abbreviations should be suppressed entirely when only a
> single leading "-" appears instead of "--". However I'd rather follow
> historical practice unless it's something stupid and complex (and
> violating the principle of least surprise for users) like checking
> whether each char is a valid short option and basing the decision on
> that.

I've just checked that even when there are both -h and -e short
options glibc getopt_long_only treats -he as --help.

Felix

Re: getopt_long_only and slightly unambiguous options

[Rich Felker]

On Sun, Jan 18, 2015 at 07:27:23PM +0100, Felix Janda wrote:
> Rich Felker wrote:
> > On Sun, Jan 18, 2015 at 06:51:59PM +0100, Felix Janda wrote:
> > > Hello,
> > > 
> > > since widl from wine uses the combination, get_opt_long_only seems to
> > > be supposed to be able to differentiate between a short option "-h"
> > > and a long option "--help". Together with the possibility of option
> > > abbreviations, the behavior we are trying to copy is:
> > > 
> > > -h     -> -h
> > > --help -> --help
> > > -help  -> --help
> > > -he    -> --help
> > > --h    -> --help
> > > 
> > > However musl maps all of them to --help.
> > > 
> > > The man page is ambiguous about this aspect and I'm not sure if the
> > > BSDs have the same behavior here. (However I would suspect that the
> > > breakage in widl, when the --help option was added in 2012, would
> > > have been noticed.) As always, it is hard to measure how many
> > > applications (and scripts written against these applications) might
> > > depend on this behavior. Since getopt_long_only is discouraged
> > > maybe these are actually quite few, though.
> > > 
> > > All in all I think that this a bug in musl which should be fixed.
> > > 
> > > 
> > > For the implementation, is it maybe enough in __getopt_long_core to
> > > pass options starting with '-' and of exactly two characters
> > > directly to getopt?
> > 
> > I would think getopt_long_only would even want to treat "-he" as "-h"
> > and "-e", i.e. abbreviations should be suppressed entirely when only a
> > single leading "-" appears instead of "--". However I'd rather follow
> > historical practice unless it's something stupid and complex (and
> > violating the principle of least surprise for users) like checking
> > whether each char is a valid short option and basing the decision on
> > that.
> 
> I've just checked that even when there are both -h and -e short
> options glibc getopt_long_only treats -he as --help.

OK, so I'll go ahead with making getopt_long_core ignore abbreviations
of the form "-" followed by one character.

BTW I realized another related issue we should handle -- in the case
of long options containing multibyte characters, the abbreviation code
is wrongly accepting incomplete multibyte sequences as "abbreviations"
for the full character. I don't know if this is worth fixing, It
should be as easy as checking that the next (unmatched) byte of the
full option is either in the ASCII range or is a lead-byte.

Rich