On 01/08/2013 11:02 AM, Michal Privoznik wrote:
Going over my local git branches, I found old patch set which I was trying to get in once. Along guest IP address patches I feel like this one is desired as well and keeps returning to us from time to time.
Indeed. Furthermore, we'd want a 'virsh complete args...' command, which can be called from bash, and gives the same completion that would be provided from within interactive virsh when hitting TAB after 'args...'.
+++ b/tools/virsh.h @@ -146,6 +146,8 @@ typedef struct _vshCmdOptDef vshCmdOptDef; typedef struct _vshControl vshControl; typedef struct _vshCtrlData vshCtrlData;
+typedef char ** (*vshCmdOptCompleter) + (const vshCmdDef *cmd, const char *optname, void *opaque);
Yes, every option would need a callback function that says what completions that option would like to present (although the options of many commands can share the same function, such as a single completer for all domains, a completer for all online domains, a completer for all storage pool names, ...). Then it is a matter of wiring up the command line parser to recognize which option is next positionally, to determine which completion callback to use.
One of the biggest problem with this is - I'd have to change all of option definitions (add 'NULL, NULL, ' to all of them). Apart from huge impact, we still want command based completer, otherwise we would only complete:
Or even switch all option definitions to use C99 initializers, with { .name = "foo", .completer = fooComplete, } - but yes, we have to touch a lot of code to add it in, so we want to get the design right before starting this.
f17 f18 <...> virsh # start --domain <TAB>
Who's really typing '--domain'? The idea is to make users life easier, not harder.
If a user types --domain, then we know what to complete; but even if they don't, we often know which option is the next positional parameter (that is, our command line parser already knows that 'start foo' is shorthand for 'start --domain foo', and can thus use the --domain completer when the user types 'start TAB').
My aim to write this e-mail is: 1) let you know somebody is working on this 2) get your thoughts and opinions.
Go for it - but as others have said, also check the archives to reuse any useful starting points already out there. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org