Re: Command substitution (backtick) and tab completion

[chengiz]

On Jan 5, 12:18 pm, Eric Blake <ebl...@redhat.com> wrote:
> On 01/05/2011 09:57 AM, Greg Wooledge wrote:
>
>
>
> > On Wed, Jan 05, 2011 at 08:21:18AM -0800, chengiz wrote:
> >> So if I get this right, the only time this is a problem is when the
> >> command substitution runs more than once.
>
> > I'd actually characterize it differently: it's unsafe to run arbitrary
> > commands during tab completion, because bash doesn't know what those
> > commands might do.
>
> >> When does this happen? Not
> >> in my "ls `pwd`/<tab>" example where the command runs once and
> >> replaces itself with its output. Does it only run more than once when
> >> the ticks are not complete?
>
> > You might realize you made a mistake, hit Ctrl-U, and start over.  But
> > the backticked command has already been executed.
>
> > You might hit ESC # to comment out the command line because you suddenly
> > realize that you need to do something else first.  Then you come back to
> > it (ESC k k ...), remove the # sign, finish typing the command, and run
> > it.  But the backticked command was already executed much earlier than
> > you might have wished (two commands ago).
>
> Here's another argument why I feel that completion should NEVER rewrite
> your command line (not even to replace `pwd` with its value):
>
> I have been known to do things like this for testing parallel
> development trees:
>
> cd ~/dir<TAB>
> run tests via a single command
> HOME=/path/to/alternate/
> <up><up><enter> (to rerun cd)
> <up><up><enter> (to rerun tests, in a different directory)
>
> As long as tab completion on the cd command preserved the ~, then this
> scenario works.  But as soon as completion "helpfully" rewrites ~ into
> /path/to/home, it breaks my work flow.  Okay, so that work flow of
> abusing the definition of $HOME to swap between parallel work trees
> might not be the most common, but I hope it points out to you why
> completion should not be in the business of rewriting users commands,
> but only appending completions.  And it can be applied to any other
> situation (substitute ~/$HOME with your choice of shell variable - if
> completion ever rewrites a command line with the expansion of $var
> rather than keeping literal $var in place, then you cannot alter $var in
> between repetitions of a command - even if completion had to temporarily
> expand $var in order to form better context about what I was completing
> after the point that $var appeared in my command line).
>

Thanks for the detailed responses. They shed a lot of light on the
issue. I will probably use variables instead of backticks and
PROMPT_COMMAND to set the variables.