tab completion no longer escapes filenames and completes dirnames incorrectly (space instead of slash)

Confirming based on comment 2 in bug 742041.

Tab completion for directory name completion (appending a trailing '/'), and of handling embedded spaces in a file/directory name (by escaping the space as '\ ') appears to be fixed, (at least for the 'gedit', 'ls', 'cd' and 'mv' commands), with

tim@zaphod:~/Documents$ apt-cache policy bash bash-completion
bash:
  Installed: 4.2-0ubuntu3
  Candidate: 4.2-0ubuntu3
  Version table:
 *** 4.2-0ubuntu3 0
        500 http://nz.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
        100 /var/lib/dpkg/status
bash-completion:
  Installed: 1:1.3-1ubuntu3
  Candidate: 1:1.3-1ubuntu3
  Version table:
 *** 1:1.3-1ubuntu3 0
        500 http://nz.archive.ubuntu.com/ubuntu/ natty/main amd64 Packages
        100 /var/lib/dpkg/status
tim@zaphod:~/Documents$

It's working for me now too, but neither bash nor bash-completion were updated, and /etc/bash_completion.d is mostly full of files from April 4 (I installed from beta2 media). What happened?

I hesitate to mark fixed without understanding how.

I am encountering still the same problems. Just updated to 11.04 today. Versions of bash-completion are the same as mentioned above.

But I can add a few comments: for root everything seem to work fine, e.g.

  less /var <TAB> log <TAB> mess<TAB>

works as expected. But as a normal user I get a space after the directory instead.

Interestingly just for known commands like "less" or "ls".

The following works as expected, even as a normal user:

  foobar /var <TAB> log <TAB> mess<TAB>

11.04 ships /etc/bash_completion version 1.3, 10.10 had version 1.1. I diff'd the files, and I think there are some parts which could be responsible for this (probably when handling different bash versions) but I don't know anything about the bash completation internals, so I can't add more senseful comments to that issue ;)

Hopefully this helps nevertheless thow...

I'm seeing similar behavior, but the behavior depends on the command being used, i.e. if I use 'cd' the trailing slashes are appended to a directory name as they were in 10.10, but if I use 'ls' or 'less', they aren't.

I have 2 boxes with 11.04 installed, one is x86 and the other x86_64, both have the same behavior.

I don't see a change with the super-user account, but I don't have the super-user account enabled. Instead, I've been getting to a root shell with the 'sudo -s' command.

Last, I have the same policy set up as reported previously, i.e.

waltman@waltman-laptop:~$ apt-cache policy bash bash-completion
bash:
  Installed: 4.2-0ubuntu3
  Candidate: 4.2-0ubuntu3
  Version table:
 *** 4.2-0ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
        100 /var/lib/dpkg/status
bash-completion:
  Installed: 1:1.3-1ubuntu3
  Candidate: 1:1.3-1ubuntu3
  Version table:
 *** 1:1.3-1ubuntu3 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
        100 /var/lib/dpkg/status

After some searching, this problem appears to be caused by a conflict with 'acroread'. In 'acroread.sh' there is a function '_filedir()' which seems to override the default '_filedir()'.

Try uninstalling acroread and reinstalling from the repos. The version of Adobe Reader in the repo appears to be ok (there is an 'if' statement guarding the definition of the '_filedir()' function.

PS. 'acroread.sh' is a symlink, /etc/bash-completion.d/acroread.sh -> /opt/Adobe/Reader9/Resource/Shell/acroread_tab

@jrtokarz: I originally installed Adobe Reader from the partner repository... is there another package I'm missing?

I believe there is a bug on line 1587 of /etc/bash_completion, the "-o default" on that line should be changed to "-o filenames".

I haven't checked if 10.10 had "-o default". If it did, then I expect the changed behaviour was due to a change in the readline library. "-o default" means "tell readline to do what it thinks is default", and that may have worked in 10.10 but not in 11.04, due to a readline library change. So I think it's better to say "-o filenames" which tells readline what we want.

The reason why it works OK for root but not for the normal user is, the /etc/bash-completion script is called by $HOME/.bashrc, and this call is present in the user's .bashrc but commented out in root's .bashrc (at least on the system that I recently upgraded from 10.10 to 11.04).

I'm getting bash completion problems and I never had acroread installed on this system, so it can't be acroread in my case.

With "-o default", if I type: less /t <tab>
it expands to: less /tmp (space)
instead of less /tmp/
(but "cd /t <tab>" is OK)

"complete" is documented in "man bash" under the heading SHELL BUILTIN COMMANDS. For "-o default", it says "Use readline's default filename completion if the compspec generates no matches." For "-o filenames", it says "Tell readline that the compspec generates filenames, so it can perform any filename-specific processing (like adding a slash to directory names, quoting special characters, or suppressing trailing spaces)."

I tried changing the "-o default" to "-o filenames" and everything worked as expected.

I have not experienced a problem with "cd", only with "less" etc.

Thanks Silas (#10),
that fixed it for me too!

Silas's solution solved problem for me. Also it solves the other duplicated bugs (746380, 775386, 774430, 778681).

Developers, please change 1587 line of /etc/bash_completion and pack it to the bash-completion package. It is a great bug. It seems that many/all users of 11.04 are affected by this bug.

As well Silas' solutation works for me. Thanks.

lucid did, in fact, use "-o filenames" for its version of that for loop (line 1529).

#14 this bug is about 11.04, see Bug Description.

10.04 Lucid uses "-o filenames" (/etc/bash_completion:1529). It is OK.
10.10 Maverick uses "-o filenames" (/etc/bash_completion:1540). It is OK.
11.04 Natty uses "-o default" (/etc/bash_completion:1587). It is not OK. It is a bug, great bug!

@Norbert: I know, I am the original bug reporter after all ;-)

I do not know if the amd64 tag is appropriate, though. This is not an amd64-specific bug; I'm seeing it on my Atom netbook.

@Matt. I saw it after posting a comment. OK:)

According to packages.ubuntu.com the bash_completion package does not depend on CPU architecture. May be all two tags (amd64 and i386) are not needed.

I have both an Ubuntu Natty and a Debian Squeese boxes here. Under Debian that config it a bit different. It used default for some commands, and filenames for others.

Debian:
for i in a2ps autoconf automake bc gprof ld nm objcopy objdump readelf strip \
    bison colordiff diff patch enscript cp df dir du ln ls mkfifo mknod mv rm \
    touch vdir awk gperf grep grub indent less m4 sed shar date \
    tee who texindex cat csplit cut expand fmt fold head \
    md5sum nl od paste pr ptx sha1sum sort split tac tail tr unexpand \
    uniq wc ldd bash id irb mkdir rmdir wget curl; do
    have $i && complete -F _longopt -o filenames $i
done

# These commands do not use filenames, so '-o filenames' is not needed.
for i in env netstat seq uname units; do
    have $i && complete -F _longopt -o default $i
done
unset i

Ubuntu Natty:
for i in a2ps awk bash bc bison cat colordiff cp csplit \
    curl cut date df diff dir du enscript env expand fmt fold gperf gprof \
    grep grub head indent irb ld ldd less ln ls m4 md5sum mkdir mkfifo mknod \
    mv netstat nl nm objcopy objdump od paste patch pr ptx readelf rm rmdir \
    sed seq sha{,1,224,256,384,512}sum shar sort split strip tac tail tee \
    texindex touch tr uname unexpand uniq units vdir wc wget who; do
    have $i && complete -F _longopt -o default $i
done
unset i

It looks to me as if the Debian config does different things depending on which command is run, while in Ubutu someone tried to merge the two command blocks but got the settings wrong.

Thanks Silas (#10),
that fixed it for me too!

I think the problem is caused by the /etc/bash_completion.d/acroread.sh script, I removed this file and the problem just gone. I did not change the -o option.

i can confirm (#20):
deleted /etc/bash_completion.d/acroread.sh and the problem disappeared without modifying any othe files.

I deleted /etc/bash_completion.d/acroread.sh and it didn't work for me. Then I tried the solution of Silas (#10), the probleme is fixed.

same as Vayn, thx Silas

I reinstalled bash-completion package (without Silas #10 patch).
After update to Natty Canonical partner package source was disabled. Today I enabled this repository under Synaptic and installed 'acroread' 9.4.2 package.
Now problem is solved.

And my question is: do you updated acroread package on Natty or have installed it?

+1 for deleting acroread.sh

Fix in #10 worked for me. Thanks Silas!

+1 for silas' "-o filename" fix (#10). I did not change the acroread.sh file to fix the behavior.

spoke too soon about the "-o filename" fix... sigh.

In my case, it definitely fixes the tab completion issue, but when you start a new gnome-terminal instance, this will cause about 50-60 error messages to pop up on the start that are all the same: "-bash: complete: filename: invalid option name"

For example:
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation: https://help.ubuntu.com/

Last login: Mon Jun 6 15:57:02 2011 from <redacted>
-bash: complete: filename: invalid option name
-bash: complete: filename: invalid option name
-bash: complete: filename: invalid option name
-bash: complete: filename: invalid option name
-bash: complete: filename: invalid option name
-bash: complete: filename: invalid option name
..... same msg another 40 times....
-bash: complete: filename: invalid option name

@PeterW
-o filenames is not equal to -o filename :)

fixed it too with : -o filenames , thx #10

Fix in #10 worked for me. Thanks Silas!

+1 for Silas' fix. Oh, so good! Thanks very much. This was driving me, er, nutty.

fixed it too with using -o filenames , (#10)

^no, wait.
After changing it to -o filenames, still the completion failed for several programs
e.g. running dpkg -S /us[tab] results in /usr (then space)
Removing /etc/bash_completion.d/acroread.sh fixed it.

+1 for #34

Adding -o filenames worked for some commands (e.g. cd, ls), but not others, e.g. mplayer (no space escaping).

After removing the acroread.sh script (from adobereader-deu 9.4.2-0maverick1) it worked for mplayer as well.

On Natty, I can confirm oCean/#34 and Jörn/#35.

confirmed #34, can someone mark this as affecting adobereader-deu and adobereader-enu?

I've have ubuntu 11.04, I tried to do as you suggested but it still works.

I did silas recommended and commented out the following on around line 100 of my .bashrc file and it's working fine now:

#if [ -f /etc/bash_completion ] && ! shopt -oq posix; then
# . /etc/bash_completion
#fi

thanks!

I also confirm #34 on 11.04

I am experiencing a similar problem with Mercurial in Natty -- spaces in filenames are not escaped when I tab-complete Mercurial commands (like hg add ...). A very old version of Mercurial on Lucid had the escaping problem; when I installed a new PPA version the problem was fixed. Now I have a fresh Natty install and a PPA version of Mercurial (1.9.1) and the problem is back.

It's not acroread.sh; I definitely don't have Acrobat Reader installed and I don't have this file in /etc/bash_completion.d.

I tried changing -o default to -o filenames in /etc/bash_completion, and there was no change.

However, when I turn off sourcing /etc/bash_completion in my .bashrc, the Mercurial completion works as expected. So there is definitely something in this file which is messing things up -- but it doesn't appear to be the default/filenames change.

I haven't experienced completion problems with any other command.

Re: #41 -- I see now that when I stop sourcing /etc/bash_completion, mercurial completion doesn't work "as expected"; it just falls back to a sane default which isn't app-specific. As far as I understand, not sourcing that file turns off all application-specific completion completely, so this isn't an acceptable fix.

Also regarding #41: I found a record of the exact Mercurial version I had installed in Lucid before upgrading to Natty -- it was 1.9.0 from the releases PPA. I tried that version in Natty before trying 1.9.1 from the snapshots PPA, and neither of them works. 1.9.0 definitely worked in Lucid (and in Maverick on a different computer). So it doesn't look like this is a problem with Mercurial's completion file.

I can confirm #7, acroread.sh from the repository (9.4.2-0natty1, Ubuntu Natty 64) works. I didn't change /etc/bash_completion. All application-specific completions works.
To #22 and #23, did you login in a new bash shell after removing acroread.sh to test completion?

The bug is cause by acroread.

the function _filedir() in /etc/bash_completion.d/acroread.sh make the issue.

When commenting the function, the problem disappear.

I do not have /etc/bash_completion.d/acroread.sh but the bash_completion do not works on my Ubuntu 11.04.

+1 for removing /etc/bash_completion.d/acroread.sh fixing this issue.

Importance currently undecided... does that suggest not many people are using the command line on the desktop versions? (None of my server boxes have been upgraded to Natty, but I assume the lack of acroread would mean that the problem doesn't occur?)

This bug really bugs me! So please fix it!

@ed-mcdonagh: I would really recommend you to switch to zsh - it is that much better and the tab completion will blow you away!

I removed /etc/bash_completion.d/acroread.sh (and restarted bash) and it's working now. Thanks!

Removed /etc/bash_completion.d/acroread.sh solved the problem for me.

#10 fixed it for me too

Thanks a lot! #10 saved my sanity...

It was making me crazy!

I have the same problem in 11.10. #10 fixes it. Great!

Here's a patch to move Adobe Reader's _filedir() function to a different name, so that it doesn't interfere with the one provided in /etc/bash_completion.

The attachment "acroread_tab.patch" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

$ . /etc/bash_completion
bash: complete: filenames: invalid option name

I don't believe this is specific to acroread. I do not have that package installed at all and am experiencing the issue. Fix in #10 works for me. So, unless there is another package also providing the same conflicting _filedir() (which I was not able to find by grepping /etc/bash_completion.d/*) then the bug is specific to bash-completion. Running Oneiric, FWIW.

My situation is a little bit different, and I believe some others share my situation.
By applying the fix in #10, it only solves the problem for some commands, i.e. those listed in that for loop.
However, for commands such as mplayer and dpkg, it still does not work.
Also, I do not have file acroread.sh under /etc/bash_completion.d/
So, I cannot delete this file as others do.
I tried to move away all the files under /etc/bash_completion.d/, and the problem still remains for some commands such as xfig.
This means, if there is a problem, it has to be within /etc/bash_completion
I noticed that on my laptop, both gzip and mplayer have an autocompletion configuration file under /etc/bash_completion.d/,
and autocompletion works fine for gzip but not for mplayer.
A comparison between the configurations files reveal that:
in line 43 of gzip's configurationfile, function _compopt_o_filenames is called before autocompletion at line 44,
but for mplayer's configuration file, in the last case starting at line 253, function _filedir is invoked without calling function _compopt_o_filenames.
By adding an invocation to the function _compopt_o_filenames before line 254 in mplayer's configuration file, it makes mplayer work as expected.

This gives the idea of how to solve the problem with /etc/bash_completion
In /etc/bash_completion, line 72-126 defines the application specific autocompletion for many commands,
and they are also without calling function _compopt_o_filenames first.
However, function _compopt_o_filenames is defined in line 618, thus it cannot be called at line 72.
My fix is to paste the implementation of this function in line 623-624 before line 72.
However, there is still another problem.
The complete commands defined in line 72-126 (now 74-128) are only for filename completion.
So, the option "-o plusdirs" needs to be added to each complete command to also include the result of directory name completion.
e.g. "complete -f -X '!*.fig' xfig" -> "complete -f -o plusdirs -X '!*.fig' xfig"
After this, all the commands listed in line 74-128 work properly.

As a conclusion, this should be a bug in /etc/bash_completion and those configuration files under /etc/bash_completion.d/
My solution only fix those commands listed in /etc/bash_completion.
For commands that have a separate configuration file under /etc/bash_completion.d/, the fix should be applied to the configuration file individually.

Kubuntu 12.04: I had the same completion problem with commands cp and mv (not ls) after installing Adobe Reader.
#54 patch worked.
Thanks a lot!

As with ubuntu 12.04LTS, applying the latest updates on 04/06/12- the bug returns!

Silas Solution
'I believe there is a bug on line 1587 of /etc/bash_completion, the "-o default" on that line should be changed to "-o filenames".' saves the problem again,

Experienced this problem with Ubuntu 12.04 LTS. Installed acrobat reader about a week ago and for the last few days, have been experiencing the same problem with cp and mv commands; not sure whether it was because of the acorbat reader or the updates though.

#10 fixed it for me too! Thanks.

Same as #60, #61.

I was experiencing this problem with Ubuntu 12.04 LTS, with all (non proposed) updates applied. I have Acrobat Reader installed but didn't think it could be related to.

Before the 12.04 fresh install i had Maverick until it got unsupported so i don't know if it's new to this release.

#10 apparently fixes it.

Just had to install acroread the other day (11.10; 64-bit). Suddenly noticed I lost normal tab completion for things like ls, cp, and mv. The patch described in #54 seems to have solved the problem. Thanks!

I discovered the problem on Desktop 12.04 64 bit the other day. I installed acrobat reader a while ago but I am quite sure the problem did not occured due to this. #10 fixed it for me.

Thank you guys, post #10 helped me. I was using Ubuntu 11.04 (natty) 64bit version.

I started to suffer the same problem with command cp in Kubuntu 12.04.1 after some upgrade (I couldn't say what package is the responsible). #10 solves my problem :)

+1 for deleting acroread.sh
Tnx!

This thread saved my life

The bash tab expansion bug caused by Adobe Reader also affects Ubuntu 12.10. Comment #54 fixed the problem for me (rename acroread's _filedir() function to _acroread_filedir() in /opt/Adobe/Reader9/Resource/Shell/acroread_tab).

Additional problem with all these auto complete smarts is aliases. I have `alias ll='ls -al`, but the auto complete doesn't understand aliases so I get the random extra space after the <tab> because it didn't realise it was an 'ls'. Maybe auto-complete needs to expand aliases before applying the autocomplete?

Hi, a new acroread release (0.9.4) is available for update, could you give it a try and tell us if the problem persists?
If you still have this bug please set back the status to "new"
thanks

On Precise I have both acroread-common and acroread at 9.5.4-1precise1 version. They are not affected by this bug.

[Expired for acroread (Ubuntu) because there has been no activity for 60 days.]

Bug still present!

This is still present in 13.04. Problem does not occur when logged in as root. My .bashrc does not source /etc/bash_completion, but the problem persists. The fix from #10 doesn't make sense now since the file /etc/bash_completion has been changed by the developers since then. Acroread was never installed on this system and acroread.sh is not present.

please, just delete the /etc/bash-completion.d/acroread.sh symlink: others may have other problems but this file is just broken and break the system tab completion for no gain whatsoever. What are you waiting for yet since 2011?