bash completion: complete fully specified command
authorWolfgang Bumiller <w.bumiller@proxmox.com>
Thu, 7 Jun 2018 09:59:02 +0000 (11:59 +0200)
committerDietmar Maurer <dietmar@proxmox.com>
Fri, 8 Jun 2018 04:27:10 +0000 (06:27 +0200)
commit5082a17b81771f667e3050ddb50b2d467081d601
tree5976772dcb79ea928cbf7f3af454fc91c9cdfdcd
parent0ed806982c267da93e3c68adabef96b9a69eb117
bash completion: complete fully specified command

This contains 2 functional changes:

First: resolve_cmd no longer keeps a hash of which arguments
were expanded. This information is not required and not used
properly: For one it would conflict if the same word
appeared twice in a longer subcommand, and secondly we lose
the information when recursing into an alias anyway. And
lastly, we do not support tab completing multiple parameters
simultaneously anyway (as in, `pveum u a<tab>` does not
become `pveum user add`).
So now we simply return the expanded version of the last
command or undef if it was unknown in place of the hash we
returned previously.

The second change is how we use the new returned value:
Previously if resolve_cmd() returned a new subcommand in
$def we skipped over finishing the last word. Of course, if
the command was already fully specified (but no space put
after it), we already considered it complete and returned
the new $def.
This condition can be detected as in this case the $prev
command equals the $cur command. (Additionally, the $cur
command is either '' (after the space) or also the $prev
command (before the space), but checking this would only be
required when the same word can actually appear multiple
times in a row in a sub command chain...)
This case now takes precedence over looking through the
nested $def, so that bash will put the space after a full
command which requires another subcommand to be added.

Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
src/PVE/CLIHandler.pm