Re: Default completion bug

[Sung Pae]

On 16 Jan 2012, at 11:29 AM, Chet Ramey wrote:

> I think you've uncovered a potential problem, but not the one you
> think. The important thing is that `>' is not a command separator and
> cannot be a command name. As such, it kind of slips between the cracks
> of the completion system.

> > Of course, once a COMPSPEC for the empty string is inserted into
> > the table (which can also be done by trying to complete an empty
> > command line), completing ">" works as if one was completing the
> > empty string,

> Completing `>' *is* the same as completing the empty string, because
> `>' is not a command name, or part of a command name. If you think
> about how the shell parser operates, a sequence of characters like
> "foo>bar" is three words: the command name `foo', the operator `>' and
> the word `bar'. Removing `foo' doesn't change the meaning of `>' and
> `bar'.

I see. Trying to complete the command line:

    $ >^I

is the same as completing:

    $ "">^I

I have mistaken `>` for the command.

> > I have not attached a patch to this bug report, because I know
> > the subtle differences of rl_basic_word_break_characters,
> > COMMAND_SEPARATORS, and the value embedded in find_cmd_name(), are
> > important,

> Well, Posix says what is and what is not a command delimiter. Let's
> see if I can explain what these do a little better.

Thank you for the explanation; it's clear now. I had a suspicion the
reasoning for this was deeper than I imagined.

> While we can talk about whether or not it's reasonable to extend
> the completion system to incorporate redirections and other shell
> operators, there's no bug in the way things currently work.

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?

Cheers,
Sung Pae