Here are attached the traces resulting of completing 'ls ../fooe/'
(out.ok), and 'ls ../fooé/' (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, $C
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 w
I made a test case for this problem, see commit 3d4941f. I have to
change LC_CTYPE=C to see the problem, probably because my default locale
is en_US? You can run the test case(s) with:
./run ./unit/_filedir.exp
I was able to move the fix centrally to _quote_readline_by_ref in commit
50824f9.
Le 10/04/2010 12:30, Freddy Vulto a écrit :
> I made a test case for this problem, see commit 3d4941f. I have to
> change LC_CTYPE=C to see the problem, probably because my default locale
> is en_US? You can run the test case(s) with:
>
>./run ./unit/_filedir.exp
>
> I was able to move the
On 100412 20:52, Guillaume Rousse wrote:
> BTW, can't we also move the second eval() use (if [[ ${cur:0:1} == "'"
> && ${BASH_VERSINFO[0]} -ge 4 ]]) inside _quote_readline_by_ref function
> too, or is it harmful for directory completion ?
I think it is possible, at least the test suite gives me ok
