Re: [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.

___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel

[Bash-completion-devel] Bug#576390: bash-completion: Fails to complete after quotes.

[Philipp Weis]

Package: bash-completion
Version: 1:1.1-3
Severity: normal

Hello,

quotes confuse bash-completion, and I don't think they should. For
example:

$ mkdir p's
$ touch p\'s/test
$ ls p\'s/

Here TAB fails to complete to test. The same happens with double
quotes:

$ mkdir 'ps'
$ touch 'ps'/test
$ ls p\s/

If both folders exist, something even more surprising happens:

$ ls p\

Pressing TAB, I would expect this to complete to p\s, but instead the
trailing \ is removed, and both folders are presented as possible
completions.

Philipp


-- System Information:
Debian Release: squeeze/sid
  APT prefers unstable
  APT policy: (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bash-completion depends on:
ii  bash  4.1-2  The GNU Bourne Again SHell

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information


signature.asc
Description: Digital signature
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel