On 08/20/2013 02:30 PM, Eric Blake wrote:
I'm not a fan of this. We worked hard to get some commands (like
'virsh
echo') to NOT need a connection, and this would be undoing that work. I
think we should NOT autoconnect UNTIL we reach the point that completion
is being attempted on something where a connection is needed to get the
completer list, rather than this code which autoconnects regardless of
whether we need completion. Having 'virsh echo' avoid an autoconnect is
useful - it can be used to prove whether virsh itself is working or has
a problem such as a missing .so, without complicating the diagnosis with
a question of whether it is a bad default connection to blame.
More along that line of thought:
If I type:
$ virsh
virsh> e<TAB>
I want a completion to list all commands that start with 'e'; one of
those commands is 'echo', which does not need a connection.
Therefore, if I use the shell:
$ virsh e<TAB>
and the shell uses, under the hood,
$ virsh complete e
that particular completion attempt should NOT attempt an autoconnect,
because it is not completing on any information that requires a
connection. autoconnect to qemu:///session can be noticeably
time-consuming on the first time it is attempted. Although the session
server tends to stick around for a few seconds after the last
connection, so that future connection attempts in a short timeframe are
serviced faster, you still don't want to pay the penalty for a delay for
the first autoconnect until it is mandatory for the completion at hand.
Whereas an interactive virsh keeps one connection open across multiple
uses, the bash completion routines will be invoking a different instance
of 'virsh' for every <TAB> hit on the shell command line, where we want
each instance to be as fast as possible.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org