[Bash-completion-devel] Bug#544024: Completion with backslashes broken

EspeonEefi espeoneefi at eep.dnsalias.org
Thu Sep 3 12:35:45 UTC 2009


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

I've figured out a fix that seems to work:

--- /etc/bash_completion.orig	2009-09-03 08:21:15.229720217 -0400
+++ /etc/bash_completion	2009-09-03 08:21:36.473719600 -0400
@@ -213,6 +213,10 @@
 # results in the original argument
 quote_readline()
 {
+	if [ ${BASH_VERSINFO[0]} -gt 3 ]; then
+		echo "$1"
+		return
+	fi
 	local t="${1//\\/\\\\}"
 	echo \'${t//\'/\'\\\'\'}\' #'# Help vim syntax highlighting
 }

quote_readline() quotes its argument in a way so that readline dequoting
results in the original argument. _filedir() and _filedir_xspec() use
quote_readline() to quote the word to complete before passing it to
'compgen -d' and 'compgen -f'. Apparently, something changed in bash 4.0
that makes this unnecessary.

I'm not sure whether this is the correct long-term fix. You might also
want to re-examine the need for _filedir() and _filedir_xspec as well;
their ostensible purpose according to the comments is that "it's better
than simply using 'compgen -f', because it honours spaces in filenames,"
but it seems that modern 'compgen -f' deals with spaces just fine. Also,
I'm not sure whether this is actually a bash_completion bug or it's an
inadvertent change in the bash API for compgen that should be reverted.

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

Kernel: Linux 2.6.30-1-amd64 (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.0-4      The GNU Bourne Again SHell

bash-completion recommends no packages.

bash-completion suggests no packages.

-- no debconf information






More information about the Bash-completion-devel mailing list