[libvirt] [PATCH RFC 0/2] virsh: Introduce basic autocompletion
mprivozn at redhat.com
Tue Oct 31 14:07:26 UTC 2017
On 10/31/2017 02:43 PM, Peter Krempa wrote:
> On Tue, Oct 31, 2017 at 14:10:25 +0100, Michal Privoznik wrote:
>> This is supposed to go on the top of:
>> Before digging any deeper to this hole I want to make sure that
>> this approach is acceptable.
>> So how does this work. The idea is to have handful of generic
>> functions that fetch names (so called completers). Basically, one
>> completer per each libvirt object. The returned names are then
>> matched against (partial) user input and only matching strings
>> are then offered to the user. Moreover, among having .completer
>> each option has .completer_flags which can refine the completer's
>> For instance, in 2/2 I'm introducing virshDomainNameCompleter()
>> which does nothing more than virConnectListAllDomains(). However,
>> since it doesn't make much sense to start already running domain,
>> for the 'start' command .completer_flags is set to
>> VIR_CONNECT_LIST_DOMAINS_INACTIVE so that only inactive domains
>> are returned in the list.
>> What is missing?
>> What is implemented here are vshCmdOptDef completers. The general
>> vshCmdDef completers are still missing. Therefore:
>> virsh # start --domain<TAB><TAB>
>> works and lists inactive domains, but:
>> virsh # start<TAB><TAB>
>> doesn't (well, apart from offering options for the 'start'
>> command). While that would be certainly nice feature to have,
>> it'd require more work, because some arguments are "implicit"
>> based on position. For instance:
>> virsh # attach-interface fedora network default
>> which is equivalent to:
>> virsh # attach-interface --domain fedora --type network --source default
>> Also, bash autocompletion is missing. The idea there is to have
>> an unlisted virsh command that the bash script can call in order
>> to fetch list of options. But again, no movement in that area
> I think we need a way to determine whether the autocompletion is
> possible without any user input. For bash autocompletion you will invoke
> virsh to get any other params, but that means that for connections
> requiring authentication you'd get stuck waiting for input (or openning
> an ssh connection) which may throw off users.
Right. I haven't encountered this problem in my local (read limited)
testing. For interactive virsh instead of calling
virshConnectionHandler() I can check for:
if (!priv->conn || virConnectIsAlive(priv->conn) != 0)
This means that you'd get autocompletion only if you're connected and
your connection is valid. For bash we'd be opening autocompletion for
each run which would indeed be too expensive. On the other hand, isn't
that how every other tool does that? For instance, firewall-cmd must
connect to the daemon to fetch list of zones/rules/... On the other
hand, that connection is only local (through some UNIX socket I assume).
Long story short, we might allow autocompletion in bash only for local
More information about the libvir-list