[Bash-completion-devel] _get_cword breaks with non-ascii characters when completion files

[Guillaume Rousse]

Le 01/04/2010 22:58, Guillaume Rousse a écrit :
> With pure ascii, $COMP_POINT = ${#COMP_LINE} = 11, meaning the test is
> true, but with non ascii chars, $COMP_POINT = 13 and ${#COMP_LINE} = 12,
> meaning the test is false. It seems like an utf8 issue, with bash (or
> readline) miscouting string with multibytes characters length.
I just found this debian bug report,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472132

But it only fix part of the issue, the remaining one cause by
_quote_readline_by_ref() function, which breaks $'' string expansion by
quoting it:

+ _quote_readline_by_ref $'foo\303\251/' quoted
..
++ compgen -d -- '$'\''foo\303\251/'\'''
..
++ compgen -f -X '' -- '$'\''foo\303\251/'\'''

When replacing the quoting format (%q) by identity format (%s) in
_quote_readline_by_ref(), everything is fine:

+ _quote_readline_by_ref $'foo\303\251/' quoted
..
++ compgen -d -- $'foo\303\251/'
..
++ compgen -f -X '' -- $'foo\303\251/'

I fixed it by evaluating the result of _quote_readline_by_ref, rather
than using it directly, as it was already the case for bash4 and quoted
words. However, it only fixes files completion, not directory:
ls ~/fooé/<TAB> work
cd ~/fooé/<TAB> doesn't work

It seems the previous block, dealing with directory completion, should
also get corrected in a similar way.
-- 
BOFH excuse #352:

The cables are not the same length.