[Bash-completion-devel] squashing bug #311844 (completion for /sbin/tc)

[Igor Murzov]

On Sun, 20 Nov 2011 18:55:47 +0100
Raphaël Droz <raphael.droz+floss at gmail.com> wrote:

> I'm back with this one:
> http://alioth.debian.org/tracker/index.php?func=detail&aid=311844&group_id=100114&atid=413095
> http://www.mail-archive.com/bash-completion-devel@lists.alioth.debian.org/msg01042.html
> 
> I reworked the whole so that it's far more readable/reviewable, even
> with its 900 LOC.
 

> Git:
> http://gitorious.org/drzraf/bash-completion/blobs/master/completions/tc

Reviewed this file. Here is some strange code snippets:

> 30   COMPREPLY+=( add del replace change show list ls help )
> 31   COMPREPLY=( $(compgen -W '${COMPREPLY[@]}' -- $cur ) )

Why not use `compgen -W` at once?

> 52   [[ ${cur:${#cur}-1:1} =~ k|K|m|M|g|G|b ]] &&
> 53   COMPREPLY=( $(compgen -W "${cur}{bit,}" -- $cur ) ) ||
> 54   COMPREPLY=( $(compgen -W "${cur}{k,m,g,}{bit,}" -- $cur ) )
> 55   [[ ${cur:${#cur}-1:1} = a ]] && COMPREPLY=( )

Will this suggest "200bbit" for "200b<TAB>"? Why no completion for "200bi<TAB>"? I think this could be improved.

> 22   # if i=1 after esac; then we'll have to deal with more complex things
> 23   let i=0

> 87	    *)
> 88           i=1

> 91   [[ $i -eq 0 ]] && return 0

That's somewhat difficult to read. May be simply add returns to cases where completion finished its work?

In addition, it looks like you use tabs and use $(foo ) syntax instead of $( foo ). Ville will be angry at you ;)


-- Igor