Re: [PATCH] Allow long-options to accept more long options than one.

[Jim Meyering]

Ondřej Vašík <address@hidden> wrote:
> In RedHat Bugzilla #431005 I got complain about funny error messages in
> some coreutils commands when using more than one long option. That leads
> to funny error messages. e.g. "sleep --help --version" command will
> result to error
> "sleep: unrecognized option `--help'
> Try `sleep --help' for more information."
> I don't see any reason why to parse only one long option.
> I think that is safe to allow unlimited number of long options and break
> after first success like is done in other coreutils utilities. Therefore
> used attached patch in Fedora RAWHIDE. What do you think about that
> approach?

Hi Ondřej,

Thanks for forwarding the report and writing a patch.
I hadn't seen either.

First of all, note the "usage":

  $ sleep --help
  Usage: sleep NUMBER[SUFFIX]...
    or:  sleep OPTION
  ...
        --help     display this help and exit
        --version  output version information and exit

and how it says "OPTION", implying only one is accepted.  That
means it must reject two or more options.  I'd like to keep the existing
semantics, i.e., fail when there are two or more long options.  However,
with such a misleading diagnostic, changing parse_long_options' signature
is probably justified, in spite of all the uses.

However, note that when I build the latest upstream sources
on rawhide and run that example, I get different output:

    $ sleep --help --version
    sleep: invalid option -- -
    Try `sleep --help' for more information.
    [Exit 1]

Not much better, of course (at least it's not self-contradictory),
but this suggests rawhide has some other changes that make it say
--help is an unrecognized option.

Another reason I'd rather not use that patch is because it
would make this succeed: "sleep --help --version 60", in spite
of the "60" argument, which would be ignored.  Also, nothing
in --help suggests that sleep accepts *both* options and arguments
at the same time.  Such a change would mean adjusting the documentation
of the approximately 16 other tools in coreutils that work the same way.

One possibility is to detect and allow two or more long-named
options, but that's only a half measure: you'd get similar misbehavior
with e.g., --help plus a _short_ option, so no thanks.

Let's assume we want to diagnose problems in parse_long_options.
That's probably best, since it would have the info required to give
the most precise diagnostic -- but might also require an added exit
code parameter, if any calling program must exit with status !=
EXIT_FAILURE.  The alternative is to have the caller diagnose the
problem -- but that's not nice, since it'd mean adding very similar
code to each of the 17 caller programs.

Here's a proposal:

Add a new boolean parameter, named "strict" to make parse_long_options
accept a --help or --version option IFF it is specified as the sole
argument (as it does now), but that also makes it diagnose the first
such option as invalid if there are any other options or arguments.
Most programs would use strict=true, but not yes.c, since yes must accept
e.g., -x --help.  But uses like "sleep -x --help" and "sleep --help 60"
would both fail with a diagnostic like e.g.,

  sleep: `--help' is honored only when it is the sole option

It may be ok to exit with EXIT_FAILURE unconditionally.  To be sure,
you'll have to look at all uses in coreutils and any other package that
uses parse_long_options.  If that is the case, we can skip adding an
exit_status parameter, for now.

Are you interested in doing this?