[vim/vim] In bash syntax you can't escape a backquote in a double-quoted string. (#5991)

[Jim Hill]

paste these lines from bash_completion into an ft=bash buffer,

            [[ ${1#-a} ]] || { echo "bash_completion: $FUNCNAME:" \
                "\`$1': missing number specifier" >&2; return 1; }
            printf %d "${1#-a}" &>/dev/null || { echo bash_completion: \

you'll see that the syntax misses the end of the quoted string on the second line, it actually thinks it's inside a command substitution, a single quote will seem to terminate the string. Some dinking around shows that replacing ``"`$1 with ''"$1`restores the highlighting properly.

Environment (please complete the following information):

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Apr  4 2020 13:23:00)
Included patches: 1-510
Compiled by Arch Linux

on xterm 353, under tmux and plain, also in gvim, last synced three days ago

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[John Little]

This is a regression, the syntax/sh.vim from 2019-06-16 does not show this problem.

The maintainer of this syntax script has his own version numbering, and if you want to report problems he usually will first ask that you try the latest script from his web site, which is version 190. It has the problem.  The version on github is 189, dated 2019-10-16.  Version 188, which I have from the Ubuntu 20.04 repository, does not show the problem.  (Neither do versions 125, 133, or 179, which I had lying around.)

HTH somebody, and regards,

John Little

[Charles Campbell]

I see the problem.  As you can easily check, putting a space right
before the backslash fixes the highlighting.  From syntax highlighting's
perspective:

* something preceded by an even number of backslashes should not be
escaped (and thus be normally highlighted)
* something preceded by an odd number of backslashes should be escaped
(and thus highlighted with special highlighting)

However, in this case the backslash is preceded by the double-quote
which starts a string region.  The attempt to check for an odd/even
number of backslashes fails, and thus the backquote is recognized
incorrectly as beginning an in-string command rather than being
escaped.  Not checking for that even/odd number of backslashes is
obviously going to cause bad highlighting.  I need some way to check
that a pattern is beginning with a backslash in a region, and thus can
do without the odd-even preceding context checking.  I've asked Bram for
something like a "startgroup=..." expression (similar to nextgroup=...)
wherein I could do just that.

We'll see what happens...
Chip Campbell

[Andy Wokula]

Am 26.04.2020 um 18:03 schrieb Charles Campbell:
> John Little wrote:
>> This is a regression, the syntax/sh.vim from 2019-06-16 does not show
>> this problem.
>>
>> The maintainer of this syntax script has his own version numbering,
>> and if you want to report problems he usually will first ask that you
>> try the latest script from his web site, which is version 190. It has
>> the problem. The version on github is 189, dated 2019-10-16.
>> Version 188, which I have from the Ubuntu 20.04 repository, does not
>> show the problem. (Neither do versions 125, 133, or 179, which I had
>> lying around.)
>>
> I see the problem. As you can easily check, putting a space right
> before the backslash fixes the highlighting. From syntax
> highlighting's perspective:
>
> * something preceded by an even number of backslashes should not be
> escaped (and thus be normally highlighted)
> * something preceded by an odd number of backslashes should be escaped
> (and thus highlighted with special highlighting)
>
> However, in this case the backslash is preceded by the double-quote
> which starts a string region. The attempt to check for an odd/even
> number of backslashes fails,

maybe you just assumed this check is needed while it actually isn't?

You probably mean the following rule:

:syn match shSpecialDQ "[^\\]\zs\%(\\\\\)*\\[\\"'`$()#]"

> and thus the backquote is recognized incorrectly as beginning an
> in-string command rather than being escaped. Not checking for that
> even/odd number of backslashes is obviously going to cause bad
> highlighting.

At least for me it isn't obvious.

> I need some way to check that a pattern is beginning with a backslash
> in a region, and thus can do without the odd-even preceding context
> checking. I've asked Bram for something like a "startgroup=..."
> expression (similar to nextgroup=...) wherein I could do just that.

Try this rule instead:

:syn match shSpecialDQ "\\[\\"'`$()#]"

> We'll see what happens...
> Chip Campbell

Checking history ...

date: Thu May 10 17:35:54 2007 +0000
summary: updated for version 7.1b
-" Last Change: Sep 15, 2006
-" Version: 88
+" Last Change: Dec 12, 2006
+" Version: 89
-syn match shSpecial "\\[\\\"\'`$()#]"
+syn match shStringSpecial "\%(\\\\\)*\\[\\"'`$()#]"
+syn match shSpecial "[^\\]\zs\%(\\\\\)*\\[\\"'`$()#]"
+syn match shSpecial "^\%(\\\\\)*\\[\\"'`$()#]"

Ok, old code already included what I'm about to suggest.
So there must have been a problem ... but I can't find
a problem report.

--
Andy

[Jim Hill]

Closed #5991 as completed.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/5991/issue_event/10465500774@github.com>