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
