bash autocomplete broken when a : is in the path

[Dustin Spicuzza]

Binary package hint: bash

Say you have a directory that looks like so:

    user@machine:/var/log/gdm$ ls
    :0.log :0.log.1 :0.log.2 :0.log.3 :0.log.4 failsafe.log

and you try to view one of the files by typing

    user@machine:/var/log/gdm$ /var/log/gdm/:<TAB KEY>

Then immediately your command line will look like so:

    user@machine:/var/log/gdm$ cat /var/log/gdm/:/var/log/gdm/\:0.log

However, if you type

    user@machine:/var/log/gdm$ /var/log/gdm/\:<TAB KEY>

then it will work as expected, like so:

    user@machine:/var/log/gdm$ cat /var/log/gdm/\:0.log

Package information:

$ apt-cache policy bash bash-completion
bash:
  Installed: 3.2-0ubuntu16
  Candidate: 3.2-0ubuntu16
  Version table:
 *** 3.2-0ubuntu16 0
        500 http://us.archive.ubuntu.com hardy/main Packages
        100 /var/lib/dpkg/status
bash-completion:
  Installed: (none)
  Candidate: 20060301-3ubuntu3
  Version table:
     20060301-3ubuntu3 0
        500 http://us.archive.ubuntu.com hardy/main Packages

[Chris Jones (cmsj)]

This appears to be fixed with bash-completion 1.1 (which is in sid)

[Clint Byrum (clint-fewbar)]

I don't believe it is fixed. I'm using v 1.3 in natty, and its still not fixed.

[Rolf Leggewie (r0lf)]

does this ever occur in precise or later?

[Rolf Leggewie (r0lf)]

FWIW, I cannot reproduce this in trusty.

[Jarno Suni (jarnos)]

I can reproduce in ubuntu 14.04 (trusty)

Type the following in terminal and finally press Tabulator:
cd /tmp && mkdir test && cd test && touch :test
ls :

Then the last line is:
ls :\:test
Press enter.
ls: cannot access ::test: No such file or directory

[Rolf Leggewie (r0lf)]

Yes, indeed I was able to reproduce this now.

[Peter Cordes (peter-cordes)]

/usr/share/bash-completion/bash_completion has a bunch of stuff about treating : specially, for completing host:path in scp and similar commands. Spent a bit of time looking at the source of this behaviour, but haven't found it yet.

set -x before pressing tab, and paste that into a file to look at while going through the code seems helpful, but it's slow going.

  There's clearly a bug, though, since either it should return all files in the directory after trying to complete on :, or it should just work.

 You can work around the bug by \quoting the :, though. echo \:<TAB> works fine.

[Peter Cordes (peter-cordes)]

Apparently this is a known problem that can't be fixed. /usr/share/doc/bash-completion/README.gz FAQ says:

Q. Completion goes awry when I try to complete on something that contains
   a colon.

A. This is actually a 'feature' of bash. bash recognises a colon as
   starting a new completion token, which is often what you want when
   completing something like a PATH variable:

   $ export PATH=/bin:/sbin:/usr<Tab>

   Without the special treatment of the colon, the above wouldn't work
   without programmable completion, so it has long been a feature of
   the shell.

   Unfortunately, you don't want the colon to be treated as a special
   case when doing something like:

   $ man File::B<Tab>

   Here, the colons make bash think that it's completing the a new
   token that begins with 'B'.

   Unfortunately, there's no way to turn this off. The only thing you
   can do is escape the colons with a backslash.

So, just quote your : as \:, and roll your eyes or whatever you have to do.

I would change this to Won'tfix, but apparently ordinary mortals can't do that.

[Peter Cordes (peter-cordes)]

further update: comments for __ltrim_colon_completions() in /usr/share/bash-completion/bash_completion say you can

# Remove colon (:) from list of word completion separators
# COMP_WORDBREAKS=${COMP_WORDBREAKS//:}

in your .bashrc if you care more about completing names with : in them than about completing paths in :-separated lists, I guess.