[libvirt] [question] Why doesn't virsh command support an optional parameter

[Zhang Xiaohe]

于 2013年04月26日 11:35, Eric Blake 写道:
> On 04/25/2013 09:19 PM, Zhang Xiaohe wrote:
>> hi guys,
>>
>> It's hard for me to understand why doesn't virsh command support an
>> optional parameter because I think omitting a parameter and offering
>> a default value sometimes is quite convenient.
>>
>> For example:
>> $ virsh shutdown guest --mode acpi
>
> Did you mean 'virsh shutdown guest --mode' here, with a missing trailing
> argument to the --mode option?
Sorry, I intended to say that use 'virsh shutdown guest --mode' instead
of 'virsh shutdown guest --mode acpi'
>
>> The option --mode only accept string "acpi", "agent", "initctl" and
>> "signal", assuming that "acpi" is the most frequently used parameter
>> when --mode is specified, why not just using
>> $ virsh shutdown guest --mode acpi
>> instead.
>
> The default is to not specify --mode at all; if you are worried about a
> mode, then there is no way for virsh to know what mode is best for you.
>   In this particular example, while acpi works for qemu, it does not work
> for lxc; there, the best default is more likely to be initctl.  Since we
> can't make a different default per hypervisor without repeating all the
> logic of a hypervisor in virsh, this seems like a change that's not
> worth making.
I use this example to describe only the format, so just ignore what mode
really means.
>
> Also, consider what it would take to implement optional option parsing.
>   Existing scripts that used --mode=acpi are immune, but scripts that
> used '--mode acpi' as two arguments now have a problem - how do we know
> that the user didn't intend '--mode' with its default setting, and
> 'acpi' as a separate argument?
>
This does be a problem.
>>
>> Maybe this example is not very precise, but what I mean is if there is
>> an option which only accepts several candidate values and one of the
>> value is always used when it is specified, then we can make it the
>> default parameter of this option. This would be convenient and save
>> some typing.
>> Of course, this can also result in ambiguity to people who is not
>> familiar with the command. But with the help, it won't trap one very
>> long, will it?
>
> I'm unwilling to make any current option that requires an argument
> switch to becoming an option with an optional argument (because that in
> itself introduces parser ambiguities that may break scrips written
> against an older virsh).
OK, I see.
> However, there IS a request to add
> user-defined alias support to virsh.  If you find yourself frequently
> typing a given command, it would make sense to have virsh have a way to
> let you define an alias that shortens the amount of typing you have to
> do to get that alias.  It wouldn't be default out of the box, but may be
> a compromise that could help the situation you are worried about.
>
> For virsh aliases to work, someone would have to submit patches - is
> that something you are interested in writing?
>
My members and I currently are writing a new feature for qemu and this
needs to add an option to one virsh command. We are discussing whether
a default value can be offered with an optional parameter because one
of the values is always valid while the others are not. But now we'll
try another way.

Thanks,
Zhang Xiaohe