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. _______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel