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