[Bash-completion-devel] Bug#551780: Bug#551780: Alternate solution -- stop resolving in bash_completion

Crestez Dan Leonard cdleonard at gmail.com
Sat Jan 30 23:04:28 UTC 2010


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=( "${COMPREPLY[@]}" $(
> !                 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.






More information about the Bash-completion-devel mailing list