[libvirt] [PATCH 08/11] tools: Provide bash autompletion file

[Michal Privoznik]

On 11/08/2017 04:53 PM, Eric Blake wrote:
> On 11/08/2017 09:09 AM, Michal Privoznik wrote:
>> On 11/08/2017 03:46 PM, Martin Kletzander wrote:
>>> On Tue, Nov 07, 2017 at 01:22:56PM +0100, Michal Privoznik wrote:
>>>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> 
>>>
>>> When I see all the things you have to do here, wouldn't it be easier to
>>> have a
>>> virsh 'option' rather than a 'command' so that we don't have to parse
>>> anything
>>> twice and just circumvent the command execution in virsh itself?
>>
>> Not really. That would mean parsing the command line in cmdComplete.
>> Which again might be incomplete and thus yet more code would be needed.
>> I don't really see a problem with this approach - now that the bash
>> script is written.
>>
>>>   You
>>> would just
>>> run the same command with '-C' (for example) appended after the program
>>> name.
>>
>> Yeah, there are dozen of other approaches. I've chosen this one. I'm
>> failing to see why one is better than another one.
>>
> 
> [I haven't read this thread closely yet, just adding a drive-by comment]
> 
> Several years ago, when autocompletion was attempted (and failed) as a
> GSoC project, I had several ideas on how completion should work, and how
> it should be tested.
> 
> Ideally, we need a new virsh command 'complete', which takes varargs,
> and then performs completion based on those args.  So the bash script
> for completion for this scenario:
> 
> $ virsh some-command --arg partial<TAB><TAB>
> 
> is as simple as having the completion function in bash call:
> 
> $ virsh complete some-command --arg partial<TAB><TAB>

This is excatly what my patches are doing. With one tiny difference. In
fact bash script calls:

  virsh complete "some-command --arg partial"

so that I can have cmdComplete which takes exactly one string argument.
Parsing of the string is then done within cmdComplete. I don't think
that we have variable args in virsh for commands, do we?

> 
> The complete command in virsh should then know that it is performing
> completion on some-command, and do enough arg parsing to determine how
> to complete 'partial' in the current context of whatever argument
> some-command would be parsing at that point.
> 
> If a user in bash backs up the cursor and types <TAB> somewhere other
> than the end of the line, hopefully bash gives us enough hooks to call
> 'virsh complete args-up-to-TAB' by merely truncating whatever appears
> beyond the point where the user attempted tab completion.
> 
> ALL the completion logic lives in virsh, nothing in bash - all bash has
> to do is insert 'complete' and call into virsh.  That is, once you've
> written the bash script, it should NEVER need future modification,
> because any further improvements to completion will live in virsh
> (whether you use virsh in interactive mode or in batch mode from the shell).

Correct. And again, my patches do this. For instance:

  virsh -r -c qemu+ssh://host/system domifaddr --domain<TAB><TAB>

becomes:

  virsh -r -c qemu+ssh://host/system complete "domifaddr --domain"

And it's the 'complete' command that is responsible for bringing up a
list of possible strings.

Michal