3 ms·

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

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 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.

macrael 6y ago
We use shellcheck all the time. Any real differences in between these three parsers?
- brendanfalk 6y ago
  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!
  - bewuethr 6y ago
    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.
pforret 6y ago
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.
- brendanfalk 6y ago
  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
pabs3 6y ago
Morbig is another interesting shell parser project: https://github.com/colis-anr/morbig https://github.com/colis-anr/morbig

macrael 6y ago

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

brendanfalk 6y ago
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!
- bewuethr 6y ago
  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.

pforret 6y ago

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.

brendanfalk 6y ago
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

pabs3 6y ago

Morbig is another interesting shell parser project: https://github.com/colis-anr/morbig https://github.com/colis-anr/morbig