Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #11439

Re: bash completion escaping bug

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: bash completion escaping bug
Date 2015-08-25 11:01 -0400
Message-ID <mailman.76.1440514882.28410.bug-bash@gnu.org> (permalink)
References <CAL+bK4PZYoGhh_OJ5KB0ucxdYm+GR6jwCnJfvHq-XyqSXsBOMw@mail.gmail.com>

Show all headers | View raw


On 8/24/15 4:01 PM, Neven Sajko wrote:
> Hi,
> 
> I use bash 4.3.039 and there is a bug (not necessarily a recent
> regression) with its file name completion feature.
> for example I have this in shell input:
>   db.rc $home/Downloads/games/DOS/Captai
> and after I press Tab I have this:
>   db.rc \$home/Downloads/games/DOS/Captain\ Bible\ in\ the\ Dome\ of\
> Darkness.zip
> Notice the dollar sign which is now erroneously escaped (home is a variable).

This is a case for which you need to enable the `direxpand' option.  You've
presented the bash completion code with an ambiguous case: it needs to
backslash-escape characters in the filename that are special to the shell,
but you want some of them to be escaped (the spaces) and not others (`$').
The bash interface to the readline completion engine escapes all special
characters in the filename, and, without `direxpand', the filename it's
presented looks like this:

$home/Downloads/games/DOS/Captain Bible in the Dome of Darkness.zip

The quoted version is what you see.

Enabling `direxpand' will eliminate the ambiguity by expanding the
variable to its value before trying to quote the special characters.

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/

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: bash completion escaping bug Chet Ramey <chet.ramey@case.edu> - 2015-08-25 11:01 -0400

csiph-web