You are not logged in.
I and a co-worker are having a weird problem with ssh and bash-completion. We have a local config in .ssh/config with hosts we connect everyday. An example:
host foo
hostname foo.org
user foobar
host foobar
hostname foobar.org
user foobar
When we try to type
ssh foo<tab><tab>b<tab>
the console just freeze and we can't type anything, everything we type is ignored, but after about 30 seconds the host is completed.
This works a some time ago, so some upgrade make this happen. Anyone can reproduce this?
Offline
Yes, I am able to reproduce this.
Offline
Dammit, I have the same issue. Sorry I didn't notice this until now so I can't help in figuring out which version this issue arose in. Pretty sure it was working fine in 5.4p1-4, maybe even 5.5p1-1, so it could be in 5.6p1-1. Hope that helps..
Offline
Same issue here, openssh 5.6p1-1
Offline
I just found a solution, just start avahi-daemon and everything will work like before.
Offline
Hm, I had avahi running all the time, so never experienced the problem. Still, wtf???
never trust a toad...
::Grateful ArchDonor::
::Grateful Wikipedia Donor::
Offline
Hm, I had avahi running all the time, so never experienced the problem. Still, wtf???
I had not avahi running and it had worked until some recent upgrade. AFIK, avahi-daemon is not strict necessary.
Offline
The root of the problem is avahi-browse, which seems to hang when called sometimes if the daemon is not running. avahi-browse is used by a function _known_hosts_real (l.1321 in /etc/bash_completion), which is in turn used by /etc/bash_completion/ssh to discover local hosts using avahi. You can reproduce this by running the following command (note that for me it hung every second time it was called ):
avahi-browse -cpr _workstation._tcp
This problem is now known upstream, and there is a fix posted which works for me. It doesn't actually solve the root of the problem, namely avahi-browse hanging, but at least it does not cause bash-completion to hang too. The fix was however posted on their bug tracker in March, and has as yet not been merged into their git tree, so I'm not sure what is going on there. It looks a little hackish, so maybe they are waiting for avahi to be fixed instead.
Using avahi in _known_hosts_real was introduced in bash-completion 1.1, the original feature request can be found here. However they removed the test to see if the daemon was running in bash-completion 1.2 (something about it not working on MacOS X), thus the problem has only recently arisen (for me on 2010-07-07).
Offline
have the problem as well. @quigybo: are you saying the avahi devs are working on it? afaik debian is not an upstream for us.
< Daenyth> and he works prolifically
4 8 15 16 23 42
Offline
@dieter: the bash-completion package is from debian, and they have posted a workaround to the avahi problem as far as bash completion is concerned. I'm not sure whats going on with avahi.
Offline
Actually thinking about it, rather than using the semi-dodgy fix posted on the bug tracker, we can just test if the daemon is running since we are not on MacOS X. It is cleaner and 250 ms quicker.
--- bash_completion.orig 2010-09-14 05:33:22.000000000 +0930
+++ bash_completion 2010-09-14 05:45:04.000000000 +0930
@@ -1316,10 +1316,12 @@
# contains ";", it may mistify the result. But on Gentoo (at least),
# -k isn't available (even if mentioned in the manpage), so...
if type avahi-browse >&/dev/null; then
- COMPREPLY=( "${COMPREPLY[@]}" $( \
- compgen -P "$prefix$user" -S "$suffix" -W \
- "$( avahi-browse -cpr _workstation._tcp 2>/dev/null | \
- awk -F';' '/^=/ { print $7 }' | sort -u )" -- "$cur" ) )
+ if [ -n "$(pidof avahi-daemon)" ]; then
+ COMPREPLY=( "${COMPREPLY[@]}" $( \
+ compgen -P "$prefix$user" -S "$suffix" -W \
+ "$( avahi-browse -cpr _workstation._tcp 2>/dev/null | \
+ awk -F';' '/^=/ { print $7 }' | sort -u )" -- "$cur" ) )
+ fi
fi
# Add results of normal hostname completion, unless
This is the same test as was used in bash-completion 1.1.
Offline
I was having a problem with bash completion taking forever with rsync, starting avahi fixes the problem.
Offline
That makes sense, as rsync also uses the _known_hosts_real function. For reference here is a list of all bash-completion files that are affected (the first one being the file that has the function itself):
/etc/bash_completion
/etc/bash_completion.d/dhclient
/etc/bash_completion.d/dsniff
/etc/bash_completion.d/freeciv
/etc/bash_completion.d/gkrellm
/etc/bash_completion.d/heimdal
/etc/bash_completion.d/hping2
/etc/bash_completion.d/ldapvi
/etc/bash_completion.d/lftp
/etc/bash_completion.d/medusa
/etc/bash_completion.d/munin-node
/etc/bash_completion.d/mysqladmin
/etc/bash_completion.d/nmap
/etc/bash_completion.d/ntpdate
/etc/bash_completion.d/openldap
/etc/bash_completion.d/openssl
/etc/bash_completion.d/postgresql
/etc/bash_completion.d/rdesktop
/etc/bash_completion.d/rsync
/etc/bash_completion.d/ssh
/etc/bash_completion.d/sshfs
/etc/bash_completion.d/vncviewer
/etc/bash_completion.d/vpnc
/etc/bash_completion.d/wol
/etc/bash_completion.d/xhost
/etc/bash_completion.d/xm
Offline
Actually thinking about it, rather than using the semi-dodgy fix posted on the bug tracker, we can just test if the daemon is running since we are not on MacOS X. It is cleaner and 250 ms quicker.
--- bash_completion.orig 2010-09-14 05:33:22.000000000 +0930 +++ bash_completion 2010-09-14 05:45:04.000000000 +0930 @@ -1316,10 +1316,12 @@ # contains ";", it may mistify the result. But on Gentoo (at least), # -k isn't available (even if mentioned in the manpage), so... if type avahi-browse >&/dev/null; then - COMPREPLY=( "${COMPREPLY[@]}" $( \ - compgen -P "$prefix$user" -S "$suffix" -W \ - "$( avahi-browse -cpr _workstation._tcp 2>/dev/null | \ - awk -F';' '/^=/ { print $7 }' | sort -u )" -- "$cur" ) ) + if [ -n "$(pidof avahi-daemon)" ]; then + COMPREPLY=( "${COMPREPLY[@]}" $( \ + compgen -P "$prefix$user" -S "$suffix" -W \ + "$( avahi-browse -cpr _workstation._tcp 2>/dev/null | \ + awk -F';' '/^=/ { print $7 }' | sort -u )" -- "$cur" ) ) + fi fi # Add results of normal hostname completion, unless
This is the same test as was used in bash-completion 1.1.
Thanks quigybo, I use your patch, the issue is gone
Why does so many packages depends on Avahi? Maybe make it optdepends is
enough?
my laptop $ pacman -Qi avahi
Required By : gnome-disk-utility gnome-vfs libcups mpd sane
Offline
Thanks quigybo, I use your patch, the issue is gone
No problem.
Why does so many packages depends on Avahi? Maybe make it optdepends is enough?
Avahi isn't a hard dependency, as it tests if it is installed before trying to connect to the daemon (l.1318):
if type avahi-browse >&/dev/null; then
The problem is just that the test to see if the daemon is running was removed.
You are right that it could be added to the optional deps of bash completion though.
$ pacman -Qi bash-completion
Name : bash-completion
Version : 1.2-1
...
Depends On : bash
Optional Deps : None
Feel free to file it with our bug tracker.
Offline
Isn't there a nice way just to turn off bash completion for ssh/scp until this is fixed, it's quite bothering?
Last edited by taavi (2010-11-25 11:34:19)
Offline
Isn't there a nice way just to turn off bash completion for ssh/scp until this is fixed, it's quite bothering?
Don't press tab.
If you don't want to patch /etc/bash_completion you can instead turn off completion for any specified commands with this:
complete -r ssh scp
Offline
Thank you quigybo, that was what I needed. Tab pressing is crucial, because you want it to work on local files.
Offline
FYI, upstream fixed this issue, I'm using bash-completion-git from AUR and works like a charm.
Offline