Debian Bug report logs - #313514
bash-completion fails with e.g., ls and newlines in file names

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Anthony DeRobertis <asd@suespammers.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: bash-completion fails with e.g., ls and newlines in file names

Date: Tue, 14 Jun 2005 01:37:41 -0400

Package: bash
Version: 3.0-15
Severity: minor
File: /etc/bash_completion

anthony@bohr:foo$ touch "$(echo -e 'foo\nbar')"
anthony@bohr:foo$ ls -b
foo\nbar
anthony@bohr:foo$ ls f<tab><tab>
bar  foo  

Notice how instead of completing foo?bar (where ? = newline) it offers
to complete either foo or bar.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing'), (130, 'unstable'), (120, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.10-bohr
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages bash depends on:
ii  base-files              3.1.2            Debian base system miscellaneous f
ii  libc6                   2.3.2.ds1-22     GNU C Library: Shared libraries an
ii  libncurses5             5.4-4            Shared libraries for terminal hand
ii  passwd                  1:4.0.3-31sarge5 change and administer password and

-- no debconf information

Message #10 received at 313514@bugs.debian.org (full text, mbox, reply):

From: Mike Dornberger <Mike.Dornberger@gmx.de>

To: Debian Bug Tracking System <313514@bugs.debian.org>

Subject: Re: bash-completion fails with e.g., ls and newlines in file names - workaround

Date: Tue, 8 Nov 2005 11:29:30 +0100

Package: bash
Version: 2.05b-26
Followup-For: Bug #313514

Hi,

this bug hit me today, too, when I wanted to delete filenames with
newlines.

Completion for mv, rm and ls (haven't tested others) show this bug, even if
you use M-* (insert-completions).

$ rm fo<M-*>

results even to:

$ rm bar foo 

It does not fail on e. g. echo:

$ echo fo<tab>

$ echo 'foo
bar' 

(M-* works here correctly, too.)

Interesting point is, that it _only_ seems to break on newlines. Doing

$ touch "$(echo -e 'evil filename with\nan LF and other special chars ($bla) : , "')"
$ rm ev<M-*>

results in:

$ rm an\ LF\ and\ other\ special\ chars\ \(\$bla\)\ \:\ \,\ \" evil\ filename\ with 

As a little workaround one can either write

$ echo rm ev<tab>

or

$ xrm ev<tab>

then using C-a or Home and deleting "echo " or "x" before execution. The
last one maybe only works if there isn't a xrm file/function/alias or
something. And oh, I just found out, you can even do

$ rm ev<M-/>

(M-/ is by default bound to complete-filename. M-x BTW can be entered as ESC
x, too.)

Greetings,
 Mike

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.26-wolfden.2
Locale: LANG=C, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages bash depends on:
ii  base-files              3.1.2            Debian base system miscellaneous f
ii  libc6                   2.3.2.ds1-22     GNU C Library: Shared libraries an
ii  libncurses5             5.4-4            Shared libraries for terminal hand
ii  passwd                  1:4.0.3-31sarge5 change and administer password and

-- no debconf information

Message #15 received at 313514@bugs.debian.org (full text, mbox, reply):

From: Michael Tweedale <mpt@ic.ac.uk>

To: 313514@bugs.debian.org

Subject: Re: bash-completion fails with e.g., ls and newlines in file names - workaround

Date: Thu, 18 May 2006 12:29:44 +0100

Package: bash
Version: 3.1-4
Followup-For: Bug #313514

On  8 Nov 2005 at 11:29, Mike Dornberger wrote:
> Interesting point is, that it _only_ seems to break on newlines.

It also chokes on filenames with an equals sign:
$ touch x=y
then
$ ls x<TAB>
completes correctly;
$ ls x=<TAB>
completes (bizarrely) to x=x\=y and
$ x=<TAB>
as expected completes to a list of all filenames in cwd (though if . is
in $PATH maybe it should complete to x=y ?).

Best,
Michael

Send a report that this bug log contains spam.