From: Eric Blake
Sent: Wednesday, October 21, 2015 8:56 AM
Subject: Priority of --help
On the libvirt list, the question was raised on what happens if you have
a long command line, but then forget the arguments of an option that
requires an argument, so you try to add --help in-place to learn them.
For example:
$ ls --block-size --help
ls: invalid --block-size argument '--help'
Okay, this makes sense, '--help' is appearing in the argument position,
not as an option, so it got eaten by --block-size, and we don't get
help. So let's try again, by placing a filler for the option argument,
then our real --help attempt; and since --help is idempotent, it doesn't
matter how often it appears up front, so let's use --help as the filler:
$ ls --block-size --help --help
ls: invalid --block-size argument '--help'
Bummer. --block-size is being parsed so early that it overrides all
later options.
I mentioned on the libvirt list that use of '--help --help' is a nice
trick for getting help at more points in a command line, but which only
works for programs where option parsing cannot cause failure unless all
options have been parsed first (that is, where option parsing is a
two-pass operation, one to collect arguments and give priority to
--help, and a second to act on the collected arguments). Libvirt
happens to be an example of this:
$ virsh migrate --copy-storage-all --migrate-disks --help
error: command 'migrate' requires <domain> option
error: command 'migrate' requires <desturi> option
$ virsh migrate --copy-storage-all --migrate-disks --help --help \
| head -n2
NAME
migrate - migrate domain to another host
In the name of a better user experience, should we audit all coreutils
to find places where we have early exits during option parsing, and fix
them to be a two-pass parse so that 'program --option-that-takes-arg
--help --help' universally prints help (from the second --help that
landed in the option position) rather than complaining about the first
--help being an invalid argument to the option?