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

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?

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

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?

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

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?