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
