Hacker News Reader

Comment by brendanfalk | Hacker News Reader

This is really cool and having spoken with the lead dev, Kenneth, I trust that this will continue to be well supported.

This is built on tree-sitter, but there are a couple of other interesting shell parser projects:

  * https://github.com/mvdan/sh
  * https://github.com/koalaman/shellcheck

At Fig (https://withfig.com), we had to write a bash parser from scratch. These projects all work well in the IDE context, but in a repl environment (ie when typing in your terminal) they don't support incomplete commands very well. e.g if I type `echo "$(` the above parsers will break as the double quote and parentheses are not closed.

View on HN

I’m really interested in fig. I develop lots of bash scripts and I would love to see how new scripts can also from fig autocompletion.

Cool! Some of the biggest problems we have seen are:

  * scripts being poorly documented: what's the point of having a script if no one knows how to use it
  * scripts going stale: often built by one person / an infra team. When they break, no one knows how to fix them
  * creating scripts: bash isn't the most popular language these days, but it's still supported just about everywhere. How can we make building them easier and faster but still just as powerful

We use shellcheck all the time. Any real differences in between these three parsers?

All three are good, well maintained projects.

Tree-sitter is more general: it aims to provide support for many languages and so its bash support is lacking a little. But it's very fast. It's designed for IDEs (hence why bash-lsp is using it). It caches its results and only re-parses on newly changed code blocks.

sh by mvdan and shellcheck are both built specifically for the shell. They both have really robust grammar. shellcheck is great for error handling. sh is great for building ASTs (it's more of a true parser)

As always, it depends on your use case. If you need a descriptive summary of errors / warnings in a shell script and performance isn't crucial, use shellcheck. If you need a really robust parser and AST output, use sh. If performance is crucial and/or you eventually want to support different languages, use tree-sitter.

Please feel free to jump in if I am wrong here!

To me, the main value of sh is shfmt – I use it like gofmt and never have to think about formatting again. It also integrates with GitHub's super-linter, where you can have your preferences in an .editorconfig file and then enforce them automatically.

Morbig is another interesting shell parser project:

https://github.com/colis-anr/morbig

Reply on news.ycombinator.com