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. > 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/
