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

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ondřej Vašík on 3/13/2008 3:29 AM:
| Hello,

Hello Ondřej, and adding coreutils (as the biggest client of the
long-options module),

| 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.

Certain of the coreutils MUST special-case option parsing, in order to
more fully comply with POSIX.  For example, /bin/[ takes exactly one
option, so that '/bin/[ --help ]' obeys the POSIX rules for testing that
- --help is a non-empty string rather than outputting help.  Therefore,
'/bin/[ --help --version' must complain about a syntax error.

But for most of the coreutils, it appears that the function
parse_long_options could be made a bit nicer in the presence of multiple
long options.  Your example of 'sleep --help --version' printing usage
output seems reasonable.  The question now is whether unilaterally
changing parse_long_options() to no longer enforce argc==2 would break any
of the coreutils that intentionally rely on that behavior for POSIX
compliance.  Maybe the compromise would be changing the signature of
parse_long_options to take an additional flag on whether argc must be 2 or
can be longer.

| 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?

In the future, please send patches in a MIME format that allows inline
reading.  I'm lazy enough that I don't like saving attachments to disk
just to review them.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfZHOYACgkQ84KuGfSFAYDJNQCfbR10rSlLj3TXDDBH7JkLYT+/
9JkAn0qIDR7CcAhXsnTvXcwocBj6ttQs
=0R07
-----END PGP SIGNATURE-----