of wildcards prior to handing off for subcompletion. Also, back out change
from 1.242 (release 20020402) that set the command line token pointer to be
n-1 after expansion of any wildcards. We can't reliably know what the
position of the current token is after expansion, since someone may do
something like 'sudo ls fo*<Tab> bar', where 'fo*' expands to multiple
tokens.
- make _rpm()'s helper functions global. Having them within the _rpm() function
body doesn't make them global anyway; it just makes them get sourced at
run-time when _rpm() gets called, so this should be slightly faster
installed query completion when passed a long option that ended with 'g'.
Similarly, it would attempt uninstalled package completion instead of
installed package completion when passed a long option that ended with 'p'.
verify completion suffered from a similar bug
switch to comp{lete,gen} a shell variable
- allow group completion in bash versions > 2.04 (was > 2.05, but that would
break group completion for anyone who has installed a suitably patched 2.05)
functions, we were passing incorrect information about the current line
position when the command line contained wildcards that expanded arguments
to multiple arguments
'user:'. This gets escaped by _chown() and passed back as 'user\:'.
_command() then escapes this further to 'user\\\:', so we need to unescape it
to have things work correctly.
Unfortunately, 'sudo rm' might pass back the name of a file that has a
backslash followed by a colon in the name, e.g. 'foo\:bar'. This is
escaped by _command() to 'foo\\\:bar', which we should not unescape.
How to tell the difference between a completion that contains a backslash
that is escaping the following character, and one that has literal
backslashes?
We extract the '-o <type>' information from the compspec and, if we are
dealing with a spec that does not specify that it passes back filenames or
dirnames, we unescape any backslash/colon pairings. Of course, this means
that 'sudo chown' will still do the wrong thing when dealing with a
directory or filename that contains '\:'. Oh well...
anyway when _filedir() is called. This fixes a double escaping of trailing
backslashes when doing something like 'mv foo\<Tab>', which would cause an
eval error in _filedir()
