[conspire] curious behavior of bash completion when there's a character that needs to be escaped e.g. $

Peter Knaggs peter.knaggs at gmail.com
Wed Jan 15 11:24:10 PST 2020


I'm having this curious behavior of bash completion
on Debian 10 (buster) when I'm using environment variables in the command.
A simple example is, let's say I have the following file on my filesystem
(reading about CVE-2020-0601):

$HOME/Downloads/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF

and I type in the following command:

cp $HOME/Downloads/CSA

and then I press the [TAB] key followed by the [spacebar] key followed by
the [.] key, what happens is that bash completion mistakenly changes the
command to:

cp \$HOME/Downloads/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF .

When I press [Enter] key, I obviously get this error:

cp \$HOME/Downloads/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF  .
cp: cannot stat '$HOME/Downloads/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF': No
such file or directory

I don't think it should be escaping the $ in this scenario ($HOME is an
environment variable, after all). I guess bash is thinking that the $ is
"part of the filename" so it's escaping it, but I want bash to think of
this $ as a real $ because it's in front of the name of the environment
variable, so it shouldn't be escaped in this case. Does bash need a code
change to support this kind of thing, or is there a feature I'm missing? I
think some distros don't have this issue, but I wasn't paying close enough
attention to remember whether I just worked around the issue using "~"
instead of $HOME, e.g.:

cp ~/Downloads/CSA

and pressing [TAB] key followed by the [spacebar] key followed by the [.]
key works fine:

cp ~/Downloads/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF .

But it'd be nice to be able to use environment variables...

Thanks,
Peter.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/conspire/attachments/20200115/76b8f205/attachment.html>


More information about the conspire mailing list