[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Default completion bug

From: Chet Ramey
Subject: Re: Default completion bug
Date: Tue, 17 Jan 2012 15:25:30 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 1/16/12 3:54 PM, Sung Pae wrote:

> The only issue then is that completing a bare `<`, `>` and `>>` results
> in the default completion command receiving the redirection operator as
> its first argument. The manual, however, states (my emphasis):
>     For instance, assuming that there is a library of compspecs,
>     each kept in a file corresponding to the *name of the command*,
>     the following default completion function would load completions
>     dynamically:
>     _completion_loader()
>     {
>         . "/etc/bash_completion.d/$1.sh" >/dev/null 2>&1 && return 124
>     }
>     complete -D -F _completion_loader
> Is it not reasonable then that _completion_loader should receive the
> empty string instead of the redirection operator in this corner case?

That's an excellent point.  It's a case of these corner cases violating
one of the assumptions the programmable completion code makes.  I know
how to fix it -- the correct information exists, and is used to search
for the right compspec.  That null command just needs to be passed to
the right function.  This fix will be in the next version of bash.


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    address@hidden    http://cnswww.cns.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]