regression for completing remote files/dirs over ssh

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

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

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

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

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.

[1]: http://packages.debian.org/sid/bash-completion
[2]: https://launchpad.net/~jbernard/+ppa-packages

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!

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.

This still occurs in the Final.

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

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 'host.domain.com:/tmp/' and splits it into the three strings: 'host.domain.com', ':', 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

Thanks Marc, that patch works fine for me.

I can confirm this bug is still present in karmic.

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.

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.

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

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

Argh!

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

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 https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/482753

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?

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.

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.

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

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.

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.

And the debdiff.

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

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

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

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.

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)

Martin

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 :)

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. :)

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

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)
Host 192.168.1.1
  UserKnownHostsFile /home/user/.ssh/known_hosts

Host 192.168.1.2
  UserKnownHostsFile /home/user/.ssh/known_hosts

Host 192.168.1.3
  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.1 !192.168.1.2 !192.168.1.3 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.

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 remote.host:~/my_fil[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.

Minor amendment to previous comment:

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

should read:

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

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

Hello:

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
ile

(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

zandolf: seems strange...

When I do:

touch my_file
scp my_f[TAB]

I get:

scp my_file

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

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
fi

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

This is working fine for me in lucid

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.

[1] https://wiki.ubuntu.com/StableReleaseUpdates

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