On 7/20/10 3:14 PM, Ben Pfaff wrote:
> I'm trying to learn how bash completion works, so that I can
> write completion functions for some utilities.
>
> As an experiment, I wrote the following trivial completion. It
> is intended to report that the completions for the current word
> are exactly the contents of the current word:
>
> _test () {
> COMPREPLY=(${COMP_WORDS[COMP_CWORD]})
> }
> complete -F _test test
>
> I expected that, with the above, typing "test", followed by a
> word, followed by <TAB>, would cause bash just to insert a space.
> This is often what happens, but I've found some exceptions that I
> do not yet understand. For example, consider the following:
> test x=
>
> When I press <TAB>, I expected this to expand to:
> test x=
> followed by a space.
> With Debian's bash 4.1-3 (on which bash --version reports
> "version 4.1.5(1)-release"), this actually expands as:
> test x==
> followed by a space.
>
> With Debian's bash 3.2-4 ("bash 3.2.39(1)-release"), this expands
> as:
> test x=x=
> followed by a space.
Since `=' is one of the characters readline uses to break words for the
completer, ${COMP_WORDS[$COMP_CWORD]} expands to `='. It's treated as
a separate word on the line.
One of the changes between bash-3.2 and bash-4.0 was to make the
programmable completion code use the same set of characters as readline
to break the line into words:
i. The programmable completion code now uses the same set of characters as
readline when breaking the command line into a list of words.
This explains the behavior difference between bash-3.2 and bash-4.1.
If you want to remove `=' from the set of characters used to break words
for completion, modify the COMP_WORDBREAKS variable.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
