On Tue, 2010-01-26 at 22:56 +1300, David Eccles (gringer) wrote: > > This bug maybe should be moved to avahi? > > The problem is in /etc/bash_completion, or at least can be fixed by modifying > /etc/bash_completion (see attached diff), so it seems reasonable to call this > a > bash-completion bug. Of course, it may be that avahi-browse isn't meant to > block > while waiting for resolution, which would then be an avahi bug. > > My attempt at patching this removes the resolve argument (-r) from > avahi-browse, > so it just spits out cached data in a parseable format (-cp). * SNIP * > if type avahi-browse >&/dev/null; then > if [ -n "$(pidof avahi-daemon)" ]; then > COMPREPLY=( "${comprep...@]}" $( > ! compgen -W "$( avahi-browse -cpr _workstation._tcp | \ > grep ^= | cut -d\; -f7 | sort -u )" -- "$cur" ) ) Your patch seems wrong. The manpage of avahi-browse states that:
If --resolve is passed items that are resolved are prefixed with "=". If you remove the -r switch the avahi-browse will return no "resolved items" and the next stage of the pipe (grep ^=) never prints anything. What you're doing is turning this into a no-op. The version in bash-completion HEAD is slightly different (uses awk instead of grep and cut) but the same considerations apply. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org