Issue: test + quotes in sh.vim

[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:

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

Thanks,

Kirill

[Kirill Dergachev]

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]

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]

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: