Filename completion BS-quotes variable references

[magagnosc]

Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib   -g -O2 -Wall
uname output: Linux gem 3.0.0-12-server #20-Ubuntu SMP Fri Oct 7 16:36:30 UTC 
2011 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.2
Patch Level: 10
Release Status: release

Description:
        Filename completion, typically by use of <tab>, causes variable 
references in the typed path to be backslash-quoted, i.e. a backslash is 
inserted before the '$'.  This does not occur when no completion matches were 
found, but rather when matches were found.  This changes the meaning of the 
command line and, among other things, prevents a double-<tab> from displaying 
possible completions.

        In bash 4.0, the variable was expanded instead.

        Note that in the simplest form, the /etc/bash_completion file is not 
involved.

Repeat-By:
        Supposing I have the following directory containing, among other 
things, project and project_list.

        export FOO=/home/me/src/work
        foo $FOO/proj<tab>

        The command line now reads

        foo \$FOO/project


Fix:
        The difference between bash 4.0 and 4.2 that accounts for this is that 
bash_filename_completion_function() is now in rl_directory_rewrite_hook instead 
of in rl_directory_completion_hook.  Consequently, in 
rl_filename_completion_function(), the directory path with the variable 
expanded does not replace users_dirname and so is not used in the returned 
matches.  Under make_quoted_replacement(), the '$' is assumed to require 
quoting.

        I have fixed the problem in a local copy by reverting to using 
rl_directory_completion_hook (set in bashline.c).  But it seems desirable to 
preserve the variable, and in that case something must be done about the 
quoting instead.  That was more than I wanted to analyze.

David Magagnosc
magagnosc@grammatech.com