Highlighting problem with ksh syntax

[Janis Papanagnou]

I just cloned https://github.com/vim/vim.git

I copied the various existing files bash.vim, sh.vim, zsh.vim
(which I'm interested in) below my local $HOME/.vim
into their respective directories syntax, indent, and ftplugin .

Opening a local test file that contains (besides other things)

if [[ "$1" = "$2" ]]
...
x=$'\v'

the above two lines were marked as containing errors;
the final closing ] and the $' and terminating ' .

These errors vanish if I type these two commands consecutively
:set syntax=bash
:set syntax=sh
I wonder why that works but not a single :set syntax=sh alone.
(Is that due to some persisting side-effect from the bash setting?)

The errors also vanish if beforehand a #!/bin/ksh line is present.

My question (or request, if allowed) would be whether the correct
syntax highlighting for ksh syntax could be automatically detected
without the double-"set syntax" kludge or requiring a shebang line.

Thanks!

I'm also curious why for bash and zsh there's own :set syntax=...
possible but :set syntax=ksh disables syntax colors completely.

Janis

[Christian Brabandt]

On Do, 28 Mai 2026, Janis Papanagnou wrote:

> I just cloned https://github.com/vim/vim.git
>
> I copied the various existing files bash.vim, sh.vim, zsh.vim
> (which I'm interested in) below my local $HOME/.vim
> into their respective directories syntax, indent, and ftplugin .
>
> Opening a local test file that contains (besides other things)
>
> if [[ "$1" = "$2" ]]
> ...
> x=$'\v'

Traditionally, the vim sh filetype supports only the very narrow
traditional (Bourne) syntax, not Bash, not ksh and not even POSIX
syntax.

However there were a few complaints over time, so a few heuristics have
been built into the sh syntax script, which tries to guess what sh
dialect is in use, e.g. by setting global variables or by inspecting the
shebang line.

I believe the above is not valid Bourne shell syntax, that's why you see
those errors.

You can read about it a bit more at :h ft-sh-syntax

Note: zsh is a separate filetype and comes with its own syntax rules. It
does in no way depend on the sh syntax. ksh however does not have it's
own filetype but uses the sh syntax script.

>
> the above two lines were marked as containing errors;
> the final closing ] and the $' and terminating ' .
>
> These errors vanish if I type these two commands consecutively
> :set syntax=bash
> :set syntax=sh
> I wonder why that works but not a single :set syntax=sh alone.
> (Is that due to some persisting side-effect from the bash setting?)
>
> The errors also vanish if beforehand a #!/bin/ksh line is present.
>
> My question (or request, if allowed) would be whether the correct
> syntax highlighting for ksh syntax could be automatically detected
> without the double-"set syntax" kludge or requiring a shebang line.
>
> Thanks!
>
> I'm also curious why for bash and zsh there's own :set syntax=...
> possible but :set syntax=ksh disables syntax colors completely.

Some time ago, it was suggested to make bash its own independent
filetype, but this has caused a bit of backlash, mainly for being
backwards incompatible, so we went back to the sh filetype by default
(and kept the unusual configuration via heuristics and additional global
vim variables).

Best,
Christian
--
Something's rotten in the state of Denmark.
-- Shakespeare

[Janis Papanagnou]

Hi Christian,

thanks for the explanation/history. - Some remarks below...

> On Do, 28 Mai 2026, Janis Papanagnou wrote:
>
> > I just cloned https://github.com/vim/vim.git
> >
> > I copied the various existing files bash.vim, sh.vim, zsh.vim
> > (which I'm interested in) below my local $HOME/.vim
> > into their respective directories syntax, indent, and ftplugin .
> >
> > Opening a local test file that contains (besides other things)
> >
> > if [[ "$1" = "$2" ]]
> > ...
> > x=$'\v'
>
> Traditionally, the vim sh filetype supports only the very narrow
> traditional (Bourne) syntax, not Bash, not ksh and not even POSIX
> syntax.
>
> However there were a few complaints over time, so a few heuristics have
> been built into the sh syntax script, which tries to guess what sh
> dialect is in use, e.g. by setting global variables or by inspecting the
> shebang line.
>
> I believe the above is not valid Bourne shell syntax, that's why you see
> those errors.

Yes, that is correct. (Actually Bourne shell 'sh' is meaningless nowadays.
The minimum expected standard is the POSIX Shell 'sh', based on ksh88.)

The [[...]] is syntax introduced by ksh(88) that is meanwhile supported
by all prominent shells, e.g. Ksh (88 and 93), Bash, and Zsh, and POSIX
at least "recognizes" that syntax.

The $'...' "ANSI strings" were introduced (I think) also by ksh (ksh93 in
this case) and is also supported by the prominent shells ksh, bash, zsh.

The points of my post were mainly that
* the double-set-syntax kludge showed an effect that was probably
an undesired side-effect that might need some attention; it could
be that these side effects are a key to make syntax highlighting
work also correctly for ksh (without that interactive kludge); I
mean, somehow it works then, so why not in the first place.
* correct highlighting of the syntax (invented by ksh and borrowed
by other shells) is provided but strangely not for Ksh (only for
Bash and Zsh it works; in zsh natively, and in bash by heuristics,
as I understand your explanations).
* given that there's syntax code/rules that are triggered for Bash
I'd have hoped that these could also be made to become effective
with Ksh.

Somehow it seems that the shell-heuristics detection seems to work for
bash but (strangely) isn't very good with ksh?

I'm lacking the Vim Syntax programming knowledge but maybe someone who
does may make something of above observations; to make ksh syntax work
as it already does with the mentioned kluge - which obviously doesn't
need any other heuristics than implicitly already present somewhere!
(It just doesn't get triggered initially. Why?)

> You can read about it a bit more at :h ft-sh-syntax

Thanks. I'll have another look to better understand the current state.

Janis