Re: bash tab variable expansion question?

[Michael Kalisz]

Hi Chet,

The shopt "direxpand" feature works as advertised (Thanks!) except that I
noticed it seems to break the name-completion of executables which are not
in you path.

Example:

(colortable16.sh is a script and executable)

$ ll colortable16.sh
-rwxr-xr-x 1 user group 1458 2009-12-03 19:18 colortable16.sh*

$ shopt | grep direxpand
direxpand       off

$ ./col<TAB>  (will expand the name to colortable16.sh => a correct
behaviour)


$ shopt -s direxpand

$ shopt | grep direxpand
direxpand       on

$ ./col<TAB>  (will NOT expand the name  colortable16.sh => Incorrect
behaviour?)

B.t.w I have the bind 'set show-all-if-ambiguous on' so I only need to
press <TAB> once.

Bug or feature? Any hints?

Thanks in advance,

Michael

> On 2/24/11 5:14 PM, Michael Kalisz wrote:
>
>> Bash Version: 4.2
>> Patch Level: 0
>> Release Status: release
>>
>> Description:
>>
>> Hi!
>>
>> Example:
>>
>> In bash, version 4.1.5(1)-release:
>>
>> $ echo $PWD/<TAB>
>> will expand the $PWD variable to your current directory
>>
>> while in bash, version 4.2.0(1)-release:
>>
>> $ echo $PWD/<TAB>
>> will just escape the $ in front of the $ variable i.e:
>>
>> $ echo \$PWD/
>> The shell-expand-line (Ctrl-Alt-e) works but before I could use just TAB
>>
>> Any hints why? Any way to get the 4.1 behavior in 4.2?
>
> I wrote, in a subsequent message in a related thread:
>
>> The difference is that bash-4.1 expanded $HOME and left the expansion
>> as part of the replacement text.  Bash-4.2 tries to leave what the
>> user typed alone, but that leads to an inherently ambiguous situation:
>> when do you quote the `$' in a filename (or, in this case, a directory
>> name)?  It could be a shell variable, and it could be a character in
>> the filename.
>
> That is the problem, in a nutshell.  I posted a partial patch at the
> end of March that applied a heuristic to avoid quoting variable
> expansions in most cases, but there was no way to get the bash-4.1
> behavior back.
>
> The attached patch adds a new shell option that, when enabled, is
> intended to restore the bash-4.1 behavior of expanding directory names
> in filenames being completed.  I have done some testing, and it seems
> to work the way I intend.  This, or some later version, will be part
> of the next bash release.  I am soliciting feedback on this iteration.
>
> I'm sending this directly to everyone who's commented negatively about
> the default bash-4.2 behavior, as well as bug-bash.  Please try the new
> option (`direxpand') and let me know if it's missing anything.  The patch
> includes the original heuristic I sent out back in March, the new shopt
> option, and updates to the documentation and test suite.  It should apply
> cleanly to bash-4.2.10.
>
> 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/
>