[libvirt] [PATCH] virsh: don't shorten incorrect arguments
https://bugzilla.redhat.com/show_bug.cgi?id=949373 Print the whole incorrect argument as specified by the user instead of the short option. Before: $ virsh --debu error: option '-d' requires an argument $ virsh ---debu error: unsupported option '- $ virsh --debu c error: option -d takes a numeric argument After: $ virsh --debu error: option '--debu' requires an argument $ virsh ---debu error: unsupported option '---debu'. See --help. $ virsh --debu c error: option --debu takes a numeric argument --- tools/virsh.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index 4cd93ca..3856f62 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -2997,7 +2997,7 @@ vshParseArgv(vshControl *ctl, int argc, char **argv) switch (arg) { case 'd': if (virStrToLong_i(optarg, NULL, 10, &debug) < 0) { - vshError(ctl, "%s", _("option -d takes a numeric argument")); + vshError(ctl, _("option %s takes a numeric argument"), argv[optind - 2]); exit(EXIT_FAILURE); } if (debug < VSH_ERR_DEBUG || debug > VSH_ERR_ERROR) @@ -3048,10 +3048,10 @@ vshParseArgv(vshControl *ctl, int argc, char **argv) } break; case ':': - vshError(ctl, _("option '-%c' requires an argument"), optopt); + vshError(ctl, _("option '%s' requires an argument"), argv[optind - 1]); exit(EXIT_FAILURE); case '?': - vshError(ctl, _("unsupported option '-%c'. See --help."), optopt); + vshError(ctl, _("unsupported option '%s'. See --help."), argv[optind - 1]); exit(EXIT_FAILURE); default: vshError(ctl, _("unknown option")); -- 1.8.1.5
On 23.04.2013 16:08, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=949373
Print the whole incorrect argument as specified by the user instead of the short option.
Before: $ virsh --debu error: option '-d' requires an argument $ virsh ---debu error: unsupported option '- $ virsh --debu c error: option -d takes a numeric argument
After: $ virsh --debu error: option '--debu' requires an argument
This doesn't make any sense at all. --debu should error out so as the next example of yours:
$ virsh ---debu error: unsupported option '---debu'. See --help. $ virsh --debu c error: option --debu takes a numeric argument ---
Michal
On 04/23/2013 04:25 PM, Michal Privoznik wrote:
On 23.04.2013 16:08, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=949373
Print the whole incorrect argument as specified by the user instead of the short option.
Before: $ virsh --debu error: option '-d' requires an argument $ virsh ---debu error: unsupported option '- $ virsh --debu c error: option -d takes a numeric argument
After: $ virsh --debu error: option '--debu' requires an argument
This doesn't make any sense at all. --debu should error out so as the next example of yours:
It's just a shortened form of '--debug'. This behavior is consistent with many other programs using long options since it's what GNU getopt_long does. Jan
On 04/23/2013 08:08 AM, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=949373
Print the whole incorrect argument as specified by the user instead of the short option.
case 'd': if (virStrToLong_i(optarg, NULL, 10, &debug) < 0) { - vshError(ctl, "%s", _("option -d takes a numeric argument")); + vshError(ctl, _("option %s takes a numeric argument"), argv[optind - 2]);
I'm not sure this gives the nicest output. With short option bundling, this results in $ tools/virsh -rd error: option '-rd' requires an argument even though the -r option was just fine, and it is really just the bundled '-d' option that has a problem. Also, I wonder if we should be using a non-NULL 5th parameter to getopt_long; if you provide a longindex parameter, then you can provide a nicer error message that mentions the full "--debug" name (rather than the user-typed abbreviation '--debu') by indexing back into the long-option table (of course, do this only when it was a long option that was misused). It's a strict improvement over what we currently have, but I'm wondering if we should try for a v2 that does even better. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 04/23/2013 06:05 PM, Eric Blake wrote:
On 04/23/2013 08:08 AM, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=949373
Print the whole incorrect argument as specified by the user instead of the short option.
case 'd': if (virStrToLong_i(optarg, NULL, 10, &debug) < 0) { - vshError(ctl, "%s", _("option -d takes a numeric argument")); + vshError(ctl, _("option %s takes a numeric argument"), argv[optind - 2]);
I'm not sure this gives the nicest output. With short option bundling, this results in
$ tools/virsh -rd error: option '-rd' requires an argument
even though the -r option was just fine, and it is really just the bundled '-d' option that has a problem.
The output is even worse with two unrecognized options: $ tools/virsh -pm error: unsupported option '.../tools/.libs/virsh'. See --help.
Also, I wonder if we should be using a non-NULL 5th parameter to getopt_long; if you provide a longindex parameter, then you can provide a nicer error message that mentions the full "--debug" name (rather than the user-typed abbreviation '--debu') by indexing back into the long-option table (of course, do this only when it was a long option that was misused).
It seems longindex is only set when the option parsing is successful. If we removed the ':' from optstring and let getopt handle the errors, it would correctly translate --deb to --debug, but keep the short options unchanged: $ tools/virsh --deb .../virsh: option '--debug' requires an argument ... $ tools/virsh -rd .../virsh: option requires an argument -- 'd' ... Maybe we should revert commit dd71fa1 ([1]) and change the message to something more generic, for example: error: See virsh --help. Jan [1] http://libvirt.org/git/?p=libvirt.git;a=commitdiff;h=dd71fa1
On 04/24/2013 05:28 AM, Ján Tomko wrote:
On 04/23/2013 06:05 PM, Eric Blake wrote:
On 04/23/2013 08:08 AM, Ján Tomko wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=949373
Print the whole incorrect argument as specified by the user instead of the short option.
case 'd': if (virStrToLong_i(optarg, NULL, 10, &debug) < 0) { - vshError(ctl, "%s", _("option -d takes a numeric argument")); + vshError(ctl, _("option %s takes a numeric argument"), argv[optind - 2]);
I'm not sure this gives the nicest output. With short option bundling, this results in
$ tools/virsh -rd error: option '-rd' requires an argument
even though the -r option was just fine, and it is really just the bundled '-d' option that has a problem.
The output is even worse with two unrecognized options: $ tools/virsh -pm error: unsupported option '.../tools/.libs/virsh'. See --help.
Oops - definitely needs fixing :)
Also, I wonder if we should be using a non-NULL 5th parameter to getopt_long; if you provide a longindex parameter, then you can provide a nicer error message that mentions the full "--debug" name (rather than the user-typed abbreviation '--debu') by indexing back into the long-option table (of course, do this only when it was a long option that was misused).
It seems longindex is only set when the option parsing is successful.
If we removed the ':' from optstring and let getopt handle the errors, it would correctly translate --deb to --debug, but keep the short options unchanged:
$ tools/virsh --deb .../virsh: option '--debug' requires an argument ...
$ tools/virsh -rd .../virsh: option requires an argument -- 'd' ...
Maybe we should revert commit dd71fa1 ([1]) and change the message to something more generic, for example: error: See virsh --help.
I'm hoping we can do better than that, but yes, it is a reasonable last-resort patch that would at least avoid confusing error messages. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
participants (3)
-
Eric Blake -
Ján Tomko -
Michal Privoznik