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.
