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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/
