On 12/03/2010 02:17 AM, Justin Clift wrote:
On 03/12/2010, at 6:34 PM, Osier Yang wrote:
> static const vshCmdOptDef opts_help[] = {
> - {"command", VSH_OT_DATA, 0, N_("Prints global help or command
specific help.")},
> - {"group", VSH_OT_DATA, 0, N_("Prints global help or help for a
group of related commands.")},
> + {"command-or-group", VSH_OT_DATA, 0, N_("Prints global help,
command specific help, or help for a group of related commands")},
> {NULL, 0, 0, NULL}
> };
>
> @@ -581,10 +580,7 @@ cmdHelp(vshControl *ctl, const vshCmd *cmd)
> const vshCmdGrp *g;
> const char *name;
>
> - name = vshCommandOptString(cmd, "command", NULL);
> -
> - if (!name)
> - name = vshCommandOptString(cmd, "group", NULL);
> + name = vshCommandOptString(cmd, "command-or-group", NULL);
NACK. This breaks backwards compatibility for anyone with scripts already using
"--command":
Two points:
1. it is very unlikely that any scripts were already using --command,
since 'virsh help --command xyz' has always been equivalent to 'virsh
help xyz', and few people type a longer command when a short will do.
2. if we install unambiguous prefix parsing, then --command is an
unambiguous prefix of --command-or-group.
For now, since there has been no release with --group, I think the
better course of action is to just keep the name --command. Only when
we introduce abbreviation support can we lengthen it to --command-or-group.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org