Handle zsh syntax

[gibfahn]

I have a bunch of scripts (not least my dotfiles) where I have to deal with both bash and zsh. However whenever I add some zsh syntax, for example [[ -n "${foo[(r)b]}" ]] && echo 'b was found.' || echo 'b was not found.', the entire file becomes highlighted as an error.

I guess possible solutions are:

1. Support zsh syntax
2. Limit the error highlighting to just the affected line
3. Recognise a magic comment to ignore issues for a particular line.

The first option sounds like a big rewrite, to the point where it's probably a different project (although supporting both would be really useful as scripts often mingle the two formats).

Unsure if the second and third options are feasible.

[zfogg]

+1

[pboushy]

Would love to see this too.

[lukelbd]

Just wanted to point out a similar thread at koalaman/shellcheck#809. Personally these two issues are the only thing keeping me from switching to zsh (I use vim with ale and vim-lsp).

[skovhus]

Just a little update here. Unfortunately we are still blocked by having a better parser for zsh. And official shellcheck support would also be great.

But the experience for zsh files should have been improved compared to when this issue originally was created. The language server doesn’t highlight any parsing issues anymore.

[gibfahn]

I saw koalaman/shellcheck#809 (comment) , which points to https://github.com/psprint/zsh-sweep . I haven't tried it, but if it works well for zsh files, integrating that instead of shellcheck for zsh might be the easiest path forward.

[hinell]

We need to port ZSH parser & lexer to a new LSP server.

If anyone is interested in porting zsh parser & lexer to the new LSP please let me know. Let's unite to create it.

I would expected it to be written by using C++/Clang/Cmake/ and other building tools. Currently ZSH uses GNU Autoconfig and some other old and outdated stuff.

[Freed-Wu]

After https://github.com/tree-sitter/tree-sitter-bash/pull/115/files, tree-sitter-bash start to try to support zsh. Is it helpful for bash-language-server to handle zsh syntax?

[hinell]

@Freed-Wu This is a huge mistake. These flags shouldn't be a part of bash syntax, cause it's likely to fail in real world dev tools.

FYI @amaanq is currently busy with writing zsh parser from scratch. Get in touch with him if anyone interested.

I think the best approach would be adopting already-existing zsh parser and provide tree-sitter api instead. It would be much better.

[kolchurinvv]

so seeing how this issue is about to celebrate it's 4th birthday, safe to say zsh support isn't coming?

[chrisgrieser]

@kolchurinvv the LSP can at least partially be used for zsh, due to its similarity to bash. I've been using this LSP mostly for zsh files, and stuff like variable renaming or symbols do work. You only have to force it to work with zsh files in your lsp configuration. (I use nvim where I just force zsh files to be interpreted as zsh for that.)

Diagnostics via shellcheck do not work though, but there is an open PR that allows you to configure the LSP to have shellcheck work on zsh files as well: #1133

not great solutions, but better than nothing.

[hinell]

@kolchurinvv ZSH is drastically different from Bash. We would need a separate ZSH lsp. Too many subtle points. Bash and zsh syntaxes aren't mutually compatible and even behave differently.

[kolchurinvv]

Fair enough. Why not close this issue then with "won't implement" or something? 🙂

[0xdevalias]

FYI @amaanq is currently busy with writing zsh parser from scratch. Get in touch with him if anyone interested.

I was curious where this zsh parser work was happening. From @amaanq's profile:

I maintain and contribute to various tree-sitter repositories, including all the upstream ones, and those under the tree-sitter-grammars org.

Within https://github.com/tree-sitter-grammars:

• https://github.com/tree-sitter-grammars/tree-sitter-zsh

  • Zsh grammar for tree-sitter

I'm not sure if this was the parser work that was being referred to, but figured I would link it here in case it was useful for this issue / related knowledge. Though note the following from the commits:

we are not done (do not use)