On Thu, Dec 8, 2011 at 23:58, Chet Ramey <chet.ra...@case.edu> wrote:
> On 12/7/11 9:43 PM, Miles Bader wrote: > > I notice that recently the behavior of bash completion w/r/t > > environment variables has changed, in a reallllly annoying way: > > This has enjoyed detailed discussion in the past, on several occasions. > > http://lists.gnu.org/archive/html/bug-bash/2011-09/msg00007.html > contains a basic summary and includes a patch that adds a `direxpand' > shell option to restore the 4.1 behavior. > > You can download a version of bash-4.2.20 with this patch already applied > from the `direxpand' branch on the bash git tree on savannah. > Bash-4.2.20 does not have `direxpand'. Did I misunderstand you? # echo $BASH_VERSION 4.2.20(1)-release # shopt -s direxpand bash: shopt: direxpand: invalid shell option name # > > If one has an environment variable like: > > > > ls=/usr/local/src > > > > and then hit <TAB> to complete the following command line: > > > > $ cd $ls/ema<TAB> > > > > where the intent is to do "cd /usr/local/src/emacs", then: > > > > * The _old_ behavior of bash was to (1) expand "$ls" to > > "/usr/local/src", and then (2) proceed to complete > > "/usr/local/src/ema" into "/usr/local/src/emacs". Handy! > > Not everyone considers that to be true. > > > > > * The _new_ behavior is to just add a backslash before "$" and then > > (apparently) try to complete on the literal-$-prefixed string -- > > which of course usually fails, as there is no such subdirectory. > > It's slightly more complicated than that, but that's the gist: a > filename containing a character that requires quoting gets quoted. > > > Given that filenames/directories containing a literal "$" are quite > > rare in general, > > Not as rare as you might think, given the existence of Windows shares > mounted on different systems. > > 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/ > > -- -Clark
