regression for completing remote files/dirs over ssh

Bug #449349 reported by Chris Jones on 2009-10-12
This bug affects 15 people
Affects Status Importance Assigned to Milestone
bash-completion (Ubuntu)

Bug Description

Binary package hint: bash-completion

"scp /tmp/somefile host.doma<Tab>" finds in my known hosts file, and I have an unlocked ssh key for that host in my keyring...

"scp /tmp/somefile<Tab>" starts completing files/dirs from /tmp/ on my local machine, not the remote one.

This worked correctly in Jaunty.

ProblemType: Bug
Architecture: amd64
Date: Mon Oct 12 10:00:01 2009
DistroRelease: Ubuntu 9.10
Package: bash-completion 1:1.0-3ubuntu2
PackageArchitecture: all
 PATH=(custom, user)
ProcVersionSignature: Ubuntu 2.6.31-13.44-generic
SourcePackage: bash-completion
Uname: Linux 2.6.31-13-generic x86_64

Chris Jones (cmsj) wrote :
Lizard (lizard) wrote :

I can confirm this issue on karmic, worked fine in Jaunty.

Arch: x86
Uname: Linux 2.6.31-13-generic i686

Changed in bash-completion (Ubuntu):
status: New → Confirmed
Chris Jones (cmsj) wrote :

http://<email address hidden>/msg01314.html indicates that this has been fixed upstream

tags: added: regression-potential
Changed in bash-completion (Ubuntu Karmic):
importance: Undecided → Medium
Chris Jones (cmsj) wrote :

I pulled the upstream fix out of git, but it doesn't apply even slightly cleanly to our version of bash-completion :(

Jon Bernard (jbernard) wrote :

I've uploaded Debian Sid's version [1] to my PPA [2], this version seems to fix the issue. It's for jaunty, but you should be able to pull the dsc and rebuild for karmic -- I'd be happy to do this if it would help. If this package works for you then we can request a sync. I'm happy to help out on this one, let me know if there's anything I can do.


Chris Jones (cmsj) wrote :

Jon: 1.1 does work, although I think there's one tiny change we need to make - in /etc/bash_completion, in _known_hosts_real there's:

1311 compgen -W "$( avahi-browse -cpr _workstation._tcp | \

on my laptop avahi-browse always seems to print dbus warnings to stderr, so I've made that line be:

1311 compgen -W "$( avahi-browse -cpr _workstation._tcp 2>/dev/null| \

and it works fine. It's slow because this is a big network with well over a hundred avahi devices, but it does work and that's what matters!

Chris Jones (cmsj) wrote :

I have no idea what hoops are required at this point in Karmic's cycle to get this included, but I'm prepared to help out as I can.

Daniel Fett (fett-ubuntu) wrote :

This still occurs in the Final.

Markus Wigge (markus-cultcom) wrote :

I can confirm this when I type "ssh <TAB>" the following occurs:

:~$ ssh bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied
bash: /dev/null: Permission denied

Marc Andrysco (marc-andrysco) wrote :

Having upgraded my machine to Karmic, this bug got on my nerves. I tracked it down, and it occurs because the '_get_cword' routine in '/etc/bash_completion' is meant for bash-3, but Karmic uses bash-4. Essentially, it takes the value '' and splits it into the three strings: '', ':', and '/tmp/', when it shouldn't be splitting it at all.

I looked through the code on Debian's bash-completion package that was posted, and they have the '_get_cword' routine split into to two different sub-routines, one for bash-3 and another for bash-4. It branches depending on the value of a variable $bash4, although that appears to be non-existent in Karmic. I hacked around this to look at the actual return of 'bash --verison', and it should work reliably for now. A true long-term solution would involve using a bash and bash-completion package that are in sync.

Anyway, I attached a patch that fixes the issue specifically by the means I outlined above. I've been using it for the past few hours now, and I haven't come across any issues. In fact, it very well may fix other bash completion issues since anything that isn't supposed to split on a colon will exhibit incorrect behavior. The only file it effects is '/etc/bash_completion'.

Marc Andrysco

Frank Siegert (fsiegert) wrote :

Thanks Marc, that patch works fine for me.

Imre Péntek (pentek-imre) wrote :

I can confirm this bug is still present in karmic.

Martin Eve (martineve) wrote :

Here's an alternate patch that I wrote that works exclusively on bash 4.

Instead of using get_cword, this patch completes where a colon was the previous token.

Martin Eve (martineve) wrote :

Just to clarify, I will test this patch out on a Jaunty install later as I believe it should also work on Bash 3.

Kudos to Marc for his patch, but this one is a mere 3 lines worth of changes in bash_completion.d/ssh

Also, can anyone qualify the function of "_expand || return 0" in _scp()? My patch has removed this with, in the results of my testing, no negative effects.

Martin Eve (martineve) wrote :

According to my last dpkg test, my patch appears to work on Jaunty also.

Martin Eve (martineve) wrote :

Here is an attached path that fixes several issues with the previous, following a discussion in #ubuntu-motu:

target is now lucid
LP: notation used in changelog
quilt patch system used

Martin Eve (martineve) wrote :


My apologies - my last message *only* is attached to the WRONG bug. Message #16 no longer applies in this thread.

Martin Eve (martineve) wrote :

Ok, here's the patch that was meant to be attached.

This addresses the issue of scp completion.

In addition it fixes the issue described at

This path should therefore close #449349 and #482753

Apologies if I've made any mistakes - this is one of my first patch contributions and I'm still getting used to Ubuntu packaging/MOTU/sponsors process.

can anyone give a patch for anyone actually running Karmic or should we just wait for the update?

Martin Eve (martineve) wrote :

Andrew: devs had summit last week, so it's slow going on patch review.

In the meantime, you can copy this attached file over your /etc/bash_completion.d/ssh file and you will again have support.

humble_coffee (humblecoffee) wrote :

Martin, I your version of /etc/bash_completion.d/ssh a whirl and had it did indeed fix it. Thanks!

I found some slightly odd behavior though when pressing tab straight after the ':'. If I enter $ scp '[host]:' and then press tab, it auto completes like this: "$ scp [host]:::1:"

Successive tabs continuously appends "::1:" each time. The previous /etc/bash_completion.d/ssh wouldn't do anything when tab-completing at this point, but since it's buggy it might not be the best comparison. This behaviour strikes me as a little weird though.

Martin Eve (martineve) wrote :

humble_coffee: thanks for that - I'll try and work out what's going on there!

Martin Eve (martineve) wrote :

Here's a revised version that fixes the initial bug, as well as defaulting to homedir on remote when pressing [TAB] after ":".

Hoping to package this into a quilt patch soon.

Users on Karmic can use this until a proper patch is released.

Martin Eve (martineve) wrote :

And one further fix to the above attached here.

Would appreciate a sponsorship review of the debdiff attached, while the "ssh" attached can be used by current users.

Martin Eve (martineve) wrote :

And the debdiff.

Steve Beattie (sbeattie) on 2009-11-30
tags: added: karmic regression-release
removed: regression-potential

I tried the ssh file as provided by Martin in #24 and it didn't work for me. Do you need to do something special after copying it under /etc/bash_completion.d/ ??

Running 9.10. with dpkg -l | grep bash
ii bash 4.0-5ubuntu2 The GNU Bourne Again SHell
ii bash-completion 1:1.0-3ubuntu2 programmable completion for the bash shell

root@expresso2:/usr/local/lib# ls -la /etc/bash_completion.d/ssh*
-rw-r--r-- 1 root root 3048 2009-12-25 19:49 /etc/bash_completion.d/ssh
-rw-r--r-- 1 root root 3012 2009-12-25 19:49 /etc/bash_completion.d/ssh.orig

root@expresso2:/usr/local/lib# md5sum /etc/bash_completion.d/ssh*
750abe446fa13a07436a933ac4e11b30 /etc/bash_completion.d/ssh
a8f39f91c0bcca0ef05e2c2480f6aecb /etc/bash_completion.d/ssh.orig

Martin Eve (martineve) wrote :

Jerome: did you restart bash once you'd replaced it?

Martin Eve (martineve) wrote :

(also, can I confirm that you definitely have passwordless ssh working please?)

Bambitroll (juan-btcorp) wrote :

Martin, I have the same behavior as Jerome's... I used the last ssh file you provided, and have since then restarted my machine twice to no avail.
I use key authentication between the machine so I can log onto the remote one only with "ssh hostname", so I guess I am passwordless right? :)

I also have the same version of bash.

Martin Eve (martineve) wrote :

Hi guys,

root@expresso2:/usr/local/lib# ls -la /etc/bash_completion.d/ssh*
-rw-r--r-- 1 root root 3048 2009-12-25 19:49 /etc/bash_completion.d/ssh
-rw-r--r-- 1 root root 3012 2009-12-25 19:49 /etc/bash_completion.d/ssh.orig

Can you try moving the ssh.orig file out of the directory please?

It could be that the backup file is being included by the bash completion script (it includes all under that dir)

(alternatively, it could be that my patch isn't working in your cases - but let's try removing the backups first)


Bambitroll (juan-btcorp) wrote :

Martin, this was the problem indeed! I removed the ssh.orig I had in /etc/bash_completion.d and now all is fine.
Thanks a bunch for your help :)

Frank Siegert (fsiegert) wrote :

Martin, I had the same problem after applying your fix, and removing the backup file was the problem as well. Thanks for following up on this, hope your patch makes it into an official update soon. :)

Martin Eve (martineve) wrote :

No problems guys; hope some sponsorship review can take place soon :p

Tim Watt (timw-at-work) wrote :

re: fix in comment 20

This fails (attempts to execute /home/user/.ssh/known_hosts) in a scenario like the following:

# snippet of ~/.ssh/config
# subnet of frequently-changing hosts we trust
Host 192.168.1.*
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null

# some long-living hosts (to allow scripted access)
  UserKnownHostsFile /home/user/.ssh/known_hosts

  UserKnownHostsFile /home/user/.ssh/known_hosts

  UserKnownHostsFile /home/user/.ssh/known_hosts

If you're reading this comment, here is a workaround which simply excludes the trusted hosts from the original rule:
Host ! ! ! 192.168.1.*
  UserKnownHostsFile /dev/null

The above workaround also seems to work with the original karmic bash_completion.d/ssh (1:1.0-3ubuntu2).
In particular, before the workaround, I had multiple different UserKnownHostsFile overrides (each for a distinct Host entry). Those UserKnownHostsFile lines above were the only ones in the ~/.ssh/config file.

If my comment is a manifestation of different bug from the one under discussion, then disregard it.

Martin Eve (martineve) wrote :

Hi Tim,

Could you please clarify what exactly fails? What are your symptoms? Does remote completion fail when you use my fix? Does my fix break something that worked previously?

The patch attached is meant to fix the issue arising in 9.10 (Karmic) where remote file/directory completion over SSH no longer works.

For example, scp[TAB] should (in this hypothetical scenario) complete to: scp ~/my_file

In Karmic's bash_completion script, it does not.

As nobody has reviewed the patch, I assume that an upstream fix must exist, and will be incorporated into Lucid.

Martin Eve (martineve) wrote :

Minor amendment to previous comment:

"For example, scp[TAB] should (in this hypothetical scenario) complete to: scp ~/my_file"

should read:

For example, scp[TAB] should (in this hypothetical scenario) complete to: scp

Martin Eve (martineve) wrote :

(oh and Tim, please use the revised patch in comments #23 and #24 - not #20)

zandolf (zndlf-bsr) wrote :


The fix posted by Martin in #24 works fine for me but with an exception.
Suppose you want to copy my_file from local host to remote. If I write:

scp my_f[TAB]

It completes to:

scp my_fbash: =/dev/null: No existe el fichero ó directorio

(Sorry for the Spanish, but it is the language set as default in my computer)

But if I write:

scp ./my_f[TAB]

Everything works fine

Martin Eve (martineve) wrote :

zandolf: seems strange...

When I do:

touch my_file
scp my_f[TAB]

I get:

scp my_file

zandolf (zndlf-bsr) wrote :

Indeed, it works fine for other users.
It has to be something I had changed for my user login before finding this patch...
But no idea up to now where I made the change

zandolf (zndlf-bsr) wrote :

OK, now it works
In case it could be useful for someone, I commented the following lines in ~/.bashrc

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

Nevertheless, I don't think that this is where the problem comes from because other users have those lines in their .bashrc and it works fine for them

Chris Jones (cmsj) wrote :

This is working fine for me in lucid

Changed in bash-completion (Ubuntu):
status: Confirmed → Fix Released
Benjamin Drung (bdrung) wrote :

I unsubscribed ubuntu-sponsors, because there is no debdiff for karmic to sponsor. If you want the fix in karmic, please follow the SRU process [1] and resubscribe ubuntu-sponsors once all information are provided.


Martin Eve (martineve) on 2010-04-06
tags: added: lucid
JC Hulce (soaringsky) wrote :

This has been fixed in newer versions of Ubuntu. The fix will not get backported to Karmic, because Karmic is EOL

Changed in bash-completion (Ubuntu Karmic):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers