On 11/16/2012 03:51 AM, Jiri Denemark wrote: > On Thu, Nov 08, 2012 at 12:39:45 -0500, Laine Stump wrote: >>>> On Thu, Nov 08, 2012 at 03:24:07PM +0100, Daniel P. Berrange wrote: >>>>> >>>>> NACK to this patch. I think the current command names are good. >>>>> Creating duplicates will make life worse. First, it creates >>>>> divergance from the similarly named commands for networks, >>>>> storage and other objects. It also means scripts written again >>>>> the new commands will not work with existing libvirt. >> >> I'm putting my vote with Dan on this (Just to be clear, my original >> message in this thread was written in the spirit of "well, if you're >> going to do this, then at least make sure what you're doing is >> explicitly documented"). > > Well, I'm with Dan and Laine on this. I think adding the alias for mistyped > commands was good since it made life easier for those who know what command > they want to use keep forgetting to mistype it in the same way. However, I > don't like the idea of adding synonyms for commands just because it seems > easier for someone to remember the synonyms. It may lead to confusion when > people are talking about the same thing but are used to different synonyms. > It also destroys consistency which we have now. And we are not going to > translate various commands into different languages either, are we? > > However, if we wanted to still be nice to end users, we could implement > user-defined aliases for virsh. It would give users more power since commonly > used options could be aliased as well, e.g., someone always doing p2p live > migrations could setup an alias "lm" to be "migrate --p2p --live". And anyone > could make aliases to fit their needs. And I'm suggesting just a simple text > substitution that would just replace a recognized aliase at the beginning of a > command with the definition of the alias and just parse the result as if that > was what the user typed. Indeed, allowing user-defined aliases would be nicer. I'll go ahead and revert my patch, and think about what it would take to let the user customize things instead. -- Eric Blake eblake@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list