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

[Guillaume Rousse]

Here are attached the traces resulting of completing 'ls ../fooe/<TAB>'
(out.ok), and 'ls ../fooé/<TAB>' (out.nok).

Comparing their output shows an issue with line 415 of bash_completion
file, in second test:
elif [[ "${#words[cword]}" -eq 0 ]] || [[ "$COMP_POINT" ==
"${#COMP_LINE}" ]];

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'm using bash 4.1 and readline 6.1, with all upstream patches applied,
including this one, which appeared related at first glance:
http://ftp.gnu.org/gnu/bash/bash-4.1-patches/bash41-002
-- 
BOFH excuse #314:

You need to upgrade your VESA local bus to a MasterCard local bus.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: out.ok
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20100401/65ecf15c/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: out.nok
URL: <http://lists.alioth.debian.org/pipermail/bash-completion-devel/attachments/20100401/65ecf15c/attachment.asc>