Re: Another direxpand problem in 4.3?

[Chet Ramey]

On 4/17/14, 1:30 AM, Clark Wang wrote:
> See following example with bash-4.3.11 (compiled with the default configure
> option):
> 
> [STEP 101] $ complete -r
> [STEP 102] $ shopt direxpand
> direxpand       on
> [STEP 103] $ find .
> .
> ./the-dir
> ./the-dir/file
> ./the dir
> ./the dir/file
> [STEP 104] $ foo the-<TAB>
> [STEP 104] $ foo the-dir/<TAB>
> [STEP 104] $ foo the-dir/file
> bash: foo: command not found
> [STEP 105] $ foo the\<SPACE><TAB>
> [STEP 105] $ foo the\ dir/<TAB>
> [STEP 105] $ foo /root/tmp/direxpand/the\ dir/file
> bash: foo: command not found
> [STEP 106] $
> 
> In STEP 105 the relative path was expanded to the full path. I think it
> should not.

This is a result of one of the bugs that was fixed between bash-4.1 and
bash-4.2 that eventually led to the direxpand option.  The bash directory
completion hook is supposed to return non-zero when it modifies the
directory name that is passed (in this case, it dequotes it), which tells
readline to use the modified version.  (In a nutshell, the direxpand option
tells readline to replace the word to be completed with this expansion.)
Bash-4.1 did not, which caused several problems, but had the side effect
of not causing readline to expand the directory name after bash dequoted
it.  Bash-4.2 returned non-zero consistently, which means that readline
replaces the original text with the expanded version.  Bash-4.3 does the
same.  I don't have any good ideas yet about how to avoid the problems
without expanding the directory name.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/