Re: Oddities when tab-completing filenames containing backticks

[bash-bugs]

2009/10/16 Chet Ramey <chet.ramey@case.edu>:
> You need to remember that readline understands the characters in
> rl_completer_quote_characters as those which, in pairs, delimit quoted
> substrings in the line.  It performs completion (allowing the application
> to take first crack, of course) on the substring, using the text after
> the open quote.

Then it is a bug in readline that it is incapable of
properly handling nested quotes.

> The other thing to keep in mind is that readline doesn't look past point
> when performing completion -- it only considers characters from the
> beginning of the line or a quote character up to point.

If it considered characters from the beginning of the line,
then there would be no issue.  The backtick is inside an
open single quote, and the backtick is *not* a special
character under that circumstance -- it's no more special
to Bash than the letter "j" inside an open single quote.

> My answers below are for the built-in bash completion, not
> any programmable completions you might have defined.

I don't use any programmable completion, these are all stock,
and confirmed by other users of irc://irc.freenode.net/#bash

>> Repeat-By:
>>
>>    1) '`<tab>      This causes all commands available on the system to be
>>                    listed such as `awk `bash etc., even though it's inside
>>                    single quotes.
>
> Readline does completion on substrings; it passes ` to the bash completion
> code, which performs command completion.

Again, a backtick is no more of a special character than the
letter "a" inside an open single quote.  This is incorrect
behaviour.

>>    2) '`text<tab>  This completes the filename, but it does not insert a
>>                    trailing single quote as tab-completion would usually do.
>
> Bash receives "`text"

What do you mean by that?  Didn't you say Bash is sending
that to readline?

> does command completion on `text'

How would it do completion on something that isn't there?
I did not fill in a closing single quote.

> and suppresses the append of the close quote,
> since it's usually wrong in this case.

What appended closing quote, there is none?

If you go:

   # ls '/usr/bin/mpg3<tab>

You get the following:

   # ls '/usr/bin/mpg321'

But if you have a file called /tmp/`rubble.txt and go:

   # ls '/tmp/`rub<tab>

Then you get:

   # ls '/tmp/`rubble.txt

No closing single quote.  Incorrect and inconsistent
behaviour.  Inside single quotes, a backtick is no
different from any other character allowed in filenames,
including control characters, tabs, newlines, accented
letters, line-drawing characters, dashes, exclamation
points, etc.

Another example:

   # ls '/tmp/!rub<tab>

Completes as expected with the closing single quote for:

   # ls '/tmp/!rubble.txt'

The same goes for these filenames:

   # ls '/tmp/~test.txt'
   # ls '/tmp/"test.txt'
   # ls '/tmp/$test.txt'
   # ls '/tmp/-test.txt'
   # ls '/tmp/(test.txt'
   # ls '/tmp/&test.txt'

They all close the single quote.  The only one that
messes up is the filename beginning with a backtick.

>>    3) '`dir<tab>   This completes the directory name and adds the trailing
>>                    forward slash, but not the trailing single quote.
>
> Again, appending the trailing single quote without the trailing ` is
> generally going to be wrong.

Please explain yourself.  Backticks *are not special* inside
single quotes.  Do you need a closing "h" if you have an
opening "h" in "hello world"?  No?  Then why would you need a
closing backtick which is just another normal character?  This
is obviously incorrect behaviour.

>>    4) 'text`<tab>  This completes the filename and closes the single quote
>>                    as expected.
>
> Interesting.  I don't get this behavior.

This behaviour makes snese, because it is the correct
behaviour.  The other behaviour above is the incorrect
behaviour.  A backtick is *not* special to Bash from
inside single quotes.

>>    5) '`text<tab>' When using tab-completion inside single quotes on a
>>                    filename beginning with a backtick, then it completes
>>                    the filename and adds an additional closing single quote,
>>                    e.g. '`filename.txt''
>
> Also interesting.  I get normal command completion without any closing
> quote appended.

Are you following my example exactly?  I'll provide
exact steps to reproduce, below.

Step 1:

   touch '/tmp/`example.txt'<enter>

Step 2:

   ls '/tmp/`exam'

Step 3:

   Place your cursor on top of the closing single quote,
   after the "m", and press <tab>

Result:

   touch '/tmp/`example.txt''

Compare this to:

   touch '/tmp/example.txt'
   touch '/tmp/exam<tab>'
   touch '/tmp/example.txt'

Works as expected, no double-closing-single-quote.

>>    6) '`dir<tab>'  When using tab-completion inside single quotes on a
>>                    directory name beginning with a backtick, then it
>>                    completes the directory name and adds an additional
>>                    closing single quote after the directory name and before
>>                    the forward slash, e.g. '`directory'/'
>
> I don't see this behavior either.

Steps to reproduce:

Step 1:

   mkdir '/tmp/`dir-example'

Step 2:

   ls '/tmp/`dir'

Step 3:

   Place your cursor on top of the closing single quote,
   after the "r", and press <tab>

Result:

   ls '/tmp/`dir-example'/'

Again, when using other normal characters than the
backtick, the behaviour is as expected:

   mkdir '/tmp/dir-example'
   mkdir '/tmp/dir<tab>'
   mkdir '/tmp/dir-example/'