#2226 zsh 5.8 on Debian Stretch.

[Ray Andrews]

function test2
{
# this is a comment\
is this a comment continued on the next line?
}

zsh treats the second line as code, but it highlights as a continuation of the comment.

[Neil Hodgson]

A simpler example is:

# comment \
echo "not a comment"

which displays not a comment when run with zsh or bash.

There are separate elements in the zsh documentation for continuation and comments with no information on priority.

http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#Quoting :

A character may be quoted (that is, made to stand for itself) by preceding it with a ‘\’. ‘\’ followed by a newline is ignored.

http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#Comments :

a word beginning with the third character of the histchars parameter (‘#’ by default) causes that word and all the following characters up to a newline to be ignored.

[Lex Trotman]

Bash is like zsh, it doesn't specify a priority for the line continuation vs comment, but POSIX explicitly specifies that the line continuation is removed before the tokens are recognised, and therefore before the comment is recognised.

[Ray Andrews]

Well the fact remains that all the shells I've tried do it the same way as zsh and bash. Shouldn't it work as the shell actually is?

[Kein-Hong Man]

It's not a huge bug but it can be fixed after checking and verifying bash and zsh behaviour.

I'm busy these days so anyone out there please feel free to tackle it.

I can confirm that bash handles comment lines in its own function, thus bypassing line continuation processing. I took a look at bash-5.0 sources, in parse.y [3268], in read_token (command), if the '#' char is found, then it performs discard_until ('\n'); which is a simple function that zaps everything until the newline.

Ray, there are many dusty corners in bash parsing. Thankfully, this is a low-hanging fruit that should not be too hard to fix -- one would probably take more time checking bash and zsh to verify correct behaviour. The bash parse.y is not an elegant bit of code, speaking as someone who had worked on bash highlighting for Scintilla. Heh.

[Ray Andrews]

"then it performs discard_until ('\n'); which is a simple function that zaps everything until the newline."

Perhaps it is in the shell's favor that this way of parsing is surely the simplest. As you show, it's not exactly complicated!

I sure appreciate your 'get it done' attitude, thanks, it makes reporting these things worth the trouble. So often the devs of various projects are more interested in the latest wiz-bang feature than in tidying up little bugs.

[Zufu Liu]

sh, bash, dash, ash, zsh, ksh, mksh, csh, tcsh and bash --posix mode (all from latest msys2) all don't support line continuation for comment line.

Per Shell Command Language (2.3 Token Recognition)
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

1. f the current character is a '#', it and all subsequent characters up to, but excluding, the next <newline> shall be discarded as a comment. The <newline> that ends the line is not considered part of the comment.

I think we can remove line continuation handling for comment line unless there is a shell that supports it.
Current code also has other bug (fourth line is also colored as comment):

#backslash1\
echo 1
#backslash2\\
echo 2

[Zufu Liu]

Marked as fixed (with line continuation for comment line removed, see https://github.com/ScintillaOrg/lexilla/issues/195).