Issue: test + quotes in sh.vim

41 views
Skip to first unread message

Kirill Dergachev

unread,
May 28, 2026, 12:15:44 AM (4 days ago) May 28
to vim_dev
Hello,

My initial issue was weird highlighting of double quotes inside of if blocks (probably applies to for, do, etc).
For example in

if [ "$1" = "$2" ]; then
    test "$1" = "$2"
    "$1" = "$2"
fi

each occurrence of "$1" = "$2" colors whole rhs of equal sign as string (including quotes). Then while looking for why it does that and how I could fix it came across shTestDoubleQuote and shTestSingleQuote. Pretty sure they are the reason this happens. (despite the name they do not apply to test command outside of an if block)

Is that intentional or not?
If it is not, adding matchgroup=shQuote to shTestDoubleQuote fixes the exact problem I stated, but it is a bit more complicated for single quotes: I guess they'll have to be changed from a match to a region like double quotes.

Also I don't really understand what is the reason behind separating sh___Quote and shTest___Quote groups, can't non-test ones be used instead?

Another small note: shTestSingleQuote also contains a '\\.' group. What bash syntax does that cover?

Visual demonstration of issues above:
Screenshot from 2026-05-28 00-10-07.png

(vim version 9.1, mentioned syntax groups are same on my machine and in the newest commit on master)

Thanks,
Kirill

Kirill Dergachev

unread,
May 30, 2026, 7:55:41 AM (2 days ago) May 30
to vim_dev
Did not get an answer and think the message is too far down in the mailing list, so replying to get it up.

In case the original mail was too convoluted, I could rephrase the main question into "Is different coloring of quote characters on the lhs and rhs of an equal sign inside of an if block intentional?" (see picture I attached before for example)

четверг, 28 мая 2026 г. в 07:15:44 UTC+3, Kirill Dergachev:

Janis Papanagnou

unread,
May 30, 2026, 10:27:37 AM (2 days ago) May 30
to vim...@googlegroups.com
A possible explanation...
I can just point to the fact that the POSIX standard-conforming test commands,
'test' and '[', can be considered obsolete by ksh, bash, zsh shells at least; because
their '[[' test construct expose less issues and they accepts on the right-hand-side
not only a string but a shell-pattern. Thus the RHS *might* be handled differently
because of that (in case that difference strangely made its way back to the syntax
of the POSIX-standard and historic test commands).

What I think would be sensible...
From a syntax highlighting aspect a differentiation of old and new test syntaxes
would IMO make sense because the older variants (as opposed to the newer '[[')
are symmetric in their string arguments. It should be consistent
[ string = string ] # with the same string colors
[[ string = pattern ]] # with string and pattern colors respectively
(I'm unsure whether patterns have an own special color in sh.vim , though).

And the coloring of the test commands are of course also independent of the 'if'
construct or presence of that keyword; they can stand for themselves. Just BTW,
since you mentioned the context of 'if'.

Janis

________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Kirill Dergachev <kdergac...@gmail.com>
Gesendet: Samstag, 30. Mai 2026 13:41
An: vim_dev
Betreff: Re: Issue: test + quotes in sh.vim

Did not get an answer and think the message is too far down in the mailing list, so replying to get it up.

In case the original mail was too convoluted, I could rephrase the main question into "Is different coloring of quote characters on the lhs and rhs of an equal sign inside of an if block intentional?" (see picture I attached before for example)

четверг, 28 мая 2026 г. в 07:15:44 UTC+3, Kirill Dergachev:
Hello,

My initial issue was weird highlighting of double quotes inside of if blocks (probably applies to for, do, etc).
For example in

if [ "$1" = "$2" ]; then
test "$1" = "$2"
"$1" = "$2"
fi

each occurrence of "$1" = "$2" colors whole rhs of equal sign as string (including quotes). Then while looking for why it does that and how I could fix it came across shTestDoubleQuote and shTestSingleQuote. Pretty sure they are the reason this happens. (despite the name they do not apply to test command outside of an if block)

Is that intentional or not?
If it is not, adding matchgroup=shQuote to shTestDoubleQuote fixes the exact problem I stated, but it is a bit more complicated for single quotes: I guess they'll have to be changed from a match to a region like double quotes.

Also I don't really understand what is the reason behind separating sh___Quote and shTest___Quote groups, can't non-test ones be used instead?

Another small note: shTestSingleQuote also contains a '\\.' group. What bash syntax does that cover?

Visual demonstration of issues above:

[Screenshot from 2026-05-28 00-10-07.png]

(vim version 9.1, mentioned syntax groups are same on my machine and in the newest commit on master)

Thanks,
Kirill

--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com<mailto:vim_dev+u...@googlegroups.com>.
To view this discussion visit https://groups.google.com/d/msgid/vim_dev/04193508-cff4-47a3-bb9d-7a2bfe6fcaf8n%40googlegroups.com<https://groups.google.com/d/msgid/vim_dev/04193508-cff4-47a3-bb9d-7a2bfe6fcaf8n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Kirill Dergachev

unread,
May 30, 2026, 12:47:38 PM (2 days ago) May 30
to vim_dev
The point about differentiating rhs and lhs of test construct is reasonable and to me seems like it could be the original reason there are regions like shTestDoubleQuote or shTestSingleQuote (when there exist shDoubleQuote/shSingleQuote), but they are not in fact used for test command, but rather for if blocks and some other constructs. Unraveling sh.vim to get an exhaustive list is time consuming (especially since I am not well versed in vim script), but I found this rhs/lhs differentiation applies to bodies of while and for blocks as well.

Just try this:


test "a" = "b"

if [ "a" = "b" ]; then
  test "a" = "b"
fi

if [[ "a" = "b" ]]; then
  test "a" = "b"
fi

while :; do
  test "a" = "b"
done

for zcxv in $1; do
  test "a" = "b"
done


The first test will be different from all the other ones.
At least that's how it works for me

суббота, 30 мая 2026 г. в 17:27:37 UTC+3, Janis Papanagnou:

Janis Papanagnou

unread,
May 31, 2026, 12:47:13 PM (17 hours ago) May 31
to vim...@googlegroups.com
Sorry, I don't get what you're aiming at.

To me the issue is quite obvious...

'test a = b' and '[ a = b ]' are both (equivalent) shell commands that
should be sensibly highlighted independent of their embedding context.

In their old form as '[ a = b ]' both, 'a' and 'b', are just "strings" and
should thus both be handled as such.
Where in the new forms '[[ str = pat ]]' and '[[ str == pat ]]' we have
different types of components that may deserve differentiation.

'while test a = b' is just a part of a compound command, generally
expressed as 'while any_cmd' . And with 'if any_cmd' it's accordingly.

So in 'while <cmds> ; do <cmds> ; done' the control constructs will have
their own highlighting and the embedded <cmds> will also have their own
highlighting according the rules; for the 'test' command as described above.

I don't know about the current Vim-behavior (below I spoke about a "possible
explanation"); and my explanation was certainly no (positive) valuation.

Rather (to me) the asymmetric coloring of the 'test' arguments is clearly a bug!


And there's yet more to that; if you try...
a="b"
a='b'
a=b
In the last case the b is not highlighted as in the former two cases, but all three
versions are equivalent WRT b .
(The quotes are just for grouping, necessary only if, for example, the string contains
white-space characters - or, more generally, if it contains characters defined in the
IFS variable.)

Regards,
Janis

________________________________________
Von: vim...@googlegroups.com <vim...@googlegroups.com> im Auftrag von Kirill Dergachev <kdergac...@gmail.com>

Gesendet: Samstag, 30. Mai 2026 18:32


An: vim_dev
Betreff: Re: Issue: test + quotes in sh.vim

The point about differentiating rhs and lhs of test construct is reasonable and to me seems like it could be the original reason there are regions like shTestDoubleQuote or shTestSingleQuote (when there exist shDoubleQuote/shSingleQuote), but they are not in fact used for test command, but rather for if blocks and some other constructs. Unraveling sh.vim to get an exhaustive list is time consuming (especially since I am not well versed in vim script), but I found this rhs/lhs differentiation applies to bodies of while and for blocks as well.

Just try this:


test "a" = "b"

if [ "a" = "b" ]; then
test "a" = "b"
fi

if [[ "a" = "b" ]]; then
test "a" = "b"
fi

while :; do
test "a" = "b"
done

for zcxv in $1; do
test "a" = "b"
done


The first test will be different from all the other ones.
At least that's how it works for me

[https://sun9-7.userapi.com/s/v1/ig2/451ZhhawA3w2yrEKNNbw_o8GECJ8pEeahzVF5J4N6PX9wUvuC-kN89PeTXLb5uMdtlJZOVe0eUWjtSXvDR1Xr21E.jpg?quality=95&as=32x32,48x48,72x71,108x107,160x159,240x238,360x357,438x434&from=bu&u=z9i7GQh7dFXmtVHfpbz9PLVWRHgo7It7R-UNuRl-eqA&cs=438x0]

Janis

[Screenshot from 2026-05-28 00-10-07.png]

Thanks,
Kirill

To view this discussion visit https://groups.google.com/d/msgid/vim_dev/6cda7b9a-f9de-4c68-94cb-079ebaa1d143n%40googlegroups.com<https://groups.google.com/d/msgid/vim_dev/6cda7b9a-f9de-4c68-94cb-079ebaa1d143n%40googlegroups.com?utm_medium=email&utm_source=footer>.

Reply all
Reply to author
Forward
0 new messages