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