Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #11439
| 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> |
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
Re: bash completion escaping bug Chet Ramey <chet.ramey@case.edu> - 2015-08-25 11:01 -0400
csiph-web