In bash-4.1_p9[net,nls] (same readline version): VAR=/tmp echo $VA[hit Tab] -> $VAR echo $VAR/[hit Tab] -> /tmp/ echo $VAR/[hit Tab twice] -> /tmp/[completions are shown] In bash-4.2_p20[net,nls] with readline-6.2_p1: VAR=/tmp echo $VA[hit Tab] -> $VAR echo $VAR/[hit Tab] -> \$VAR/[completions are shown] Of course, further completions don't work after that, although if one manually removes the \, completions do work (once, then \ needs to be removed again). It seems that the intention was to make variable-in-path completion work like in tcsh (where variable is not expanded in the command, but is expanded internally for the purpose of path completion), which is a welcome change, but somewhere along the way the variable name becomes "quoted". There is no mention of the changed behavior at http://tiswww.case.edu/php/chet/bash/NEWS. The behavior also seems independent of INPUTRC settings. As a side-note, completion of $VA to $VAR probably should add a terminating / instead of a space if $VAR resolves to an existing path, but I guess that would be too blatant copying from tcsh.
this is discussed in the upstream mailing list
Indeed, the summary is here: http://lists.gnu.org/archive/html/bug-bash/2011-12/msg00079.html Seems like a classic example of shooting oneself in a foot -- bash-readline interaction prevents the tcsh behavior (expand path internally, but not externally), so they had to choose between either quoting the variable, or expanding it in-line. The motivation for quoting seems to be Windows filenames with $ in the name, which is strange (the $ would be quoted anyway on Tab-completion), but oh well.
Upstream fix propagated into stable 4.2_p37.
