10 ms·

Bash-LSP: A language server for Bash

224 points by ducktective 6y ago

alsetmusic 6y ago
I clicked through to the point of skimming the documentation for tree-sitter before giving up on understanding this quickly. There are too many components that I haven’t seen for me to extrapolate out and get to what this does in general terms. Could anyone with more knowledge please explain what this is and how one might utilize it? Fwiw, I’m deeply familiar with Bash; I just don’t recognize the rest.
- sabellito 6y ago
  Language Servers are pieces of software that implement IDE-like features (like go to definition, find usages, call-hierarchy, rename method, etc) for a given language in an editor-agnostic way. With that, any editor that supports Language Servers can use those to provide better support to a language without implementing any details. In this case, you can see some of the supported editors in the README itself: https://github.com/bash-lsp/bash-language-server#clients https://github.com/bash-lsp/bash-language-server#clients
  - benatkin 6y ago
    It doesn't seem editor agnostic to me. It seems geared towards vscode. The idea is also not new - python has had docstrings since the 90s. They never thought to show the full definition on hover or autocomplete, probably because it's noise most of the time, but a lot of people seem to like it.
- zeusk 6y ago
  LSP is a protocol for IDE/editors to analyze code files and provide functionality like intelligible code search (definition, references etc)
  - benatkin 6y ago
    Arguably a protocol for Visual Studio Code to...
    - chusk3 6y ago
      That's simply not true; there are LSP client implementations/integrations for vim, neovim, emacs, sublime text, web environments like gitpod.io, Eclipse IDE (via Theia IDE), Jetbrains supports it in their IDEs, and Visual Studio even has some level of support for it. LSP is _the_ way to write IDE integrations in the modern era. (I maintain LSP tooling for F# and actively support at least half of the editors above)
      - deleted 6y ago
        [deleted]
      - benatkin 6y ago
        It's neither true nor false, it's an opinion. Sure "LSP" has support built in or tacked on (as plugins), mostly tacked on, to other editors. Nobody is required to assume TypeScript docs for a supposedly language-agnostic protocol, or that particular flavor of JSON-RPC, or JSON-RPC, or even JSON. And the pill I don't want to swallow, that people using LSP tend to swallow, is getting full definitions with autocomplete, or hover. Most of the time I prefer to just see completions when I autocomplete, not full definitions. It is clutter.
        chusk3 6y ago
        I'm not at all sure what you mean by 'typescript docs' in your comment. The protocol for things like tooltips/signature completion literally just says 'put arbitrary markdown here'. It doesn't proscribe the structure of the text the LSP author decides to use. There are also many different display/view methods that more sophisticated LSP implementations can implement. In my own LSP, we have different 'views' of the signatures/types/docs for * hovers * signature completion * detailed type-level embedded docs in a separate pane to name a few. It's entirely customizable.
- deleted 6y ago
  [deleted]
- adonovan 6y ago
  Language Server Protocol (LSP) is a standard protocol for "plain old" editors (clients) to make RPCs to local processes that understand the syntax, references, and types of a particular programming language (servers). This reduces the work to support M servers and N clients to M+N, whereas the traditional monolithic approach required M*N integrations. This particular project adds a server for Bash support.
- JoBrad 6y ago
  To add to the other comments, VSCode docs has a good overview of the motivation and usage of a Language Server. https://code.visualstudio.com/api/language-extensions/language-server-extension-guide https://code.visualstudio.com/api/language-extensions/langua...
- widdershins 6y ago
  The other comments explained what LSP is - I'll explain what tree-sitter is. It's a clever parser that is very fast when it comes to reparsing a slightly changed file (it's 'incremental'). It's also very good at handling errors and continuing to parse your file. You write a grammar in json and it gets compiled to a shared library via C.
brendanfalk 6y ago
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.
usbline 6y ago
Development tools like this with an obscene amount of dependencies, not to mention multi-language dependencies, is extremely worrying and irresponsible for the future of software development. Especially since they're not even native to bash's environment! If you would have told me 5 years ago I'd need to install node and typescript in order to get auto completion for bash, I'd have called you crazy. Yet here we are.
- nicoburns 6y ago
  What do you expect a bash language server to be written in? Bash?
  - mdip 6y ago
    You said it, sarcastically, but that didn't mean I didn't think it. At first blush it sounds a little crazy, but the more I think about it... Consider my problem: I use `zsh` and have created, collected and organized a large number of completions which I synchronize among several workstations. It frustrates me to no end that I cannot take advantage of these completions in very many other convenient places, like VSCode[0]. The benefit of writing it in `zsh` (I can't speak for bash) is that seems like it'd be pretty simple to wire up the LSB as a sort of "completions proxy" that simply takes the inputs, passes them to a completion script, parses the output and formats it in the appropriate JSON response. The utility of being able to have a single script (or set of scripts) that I can include in my shared profile directory which will run and handle a `zsh` LSB implementation on-demand (i.e. doesn't need installing, sits in my scripts directory and runs everywhere) would be a huge feature. This will speak to my ignorance, but can you host a web server (in a manner that can be consumed) from just bash and a lean environment[1]? Could you host an LSP without one (i.e. is there enough to use a socket and would it be enough to point it at the right place/scheme?). I believe there are `zsh` extensions which can facilitate some/all of this, but I'm not sure if it would work out of the box. The downside to developing it in `zsh`, other than the language itself[2] is performance. Both of those, assuming "the hosting/serving" can be handled easily, don't represent big problems, maybe they are. But performance and the language should be up to what remains outside of that. [0] I had `nvim` set up correctly, once to work with completion scripts and was able to translate that into VSCode doing the same, about two years ago. I'm still not fully convinced I didn't just dream this up because the few times I've looked into it, since, I've gotten nowhere (admittedly, I've put little effort into researching). [1] I'm thinking 'busybox', minimal gnu-related things, ideally requiring as little as possible beyond a relatively recent version of `bash` so that "if it's got bash, I can use it". [2] I use `zsh` because it's easier for me to write things in it than `bash`, and at times it can be fun. But there's a reason we don't build solutions using it. [3] Everything's a string...
gkfasdfasdf 6y ago
I have been using this for a year or so and it is awesome. I use with neovim + LanguageClient-neovim. I don't really understand why people are complaining about the dependencies - on macos just brew install node@14 and npm install -g bash-language-server. Check for updates occasionally via npm outdated -g. I really have no idea what the dependencies are other than node and nor do I care - its just another app on my system.
prussian 6y ago
Kind of cute. Jumped around with xref and found callers for functions, but can't really imagine this to be useful unless you're as crazy as I am or also responsible to insane number of these _things_. Not sure what qualifies as doc strings, I discovered you have to use two hashes for multiple lines. More documentation on that might be helpful then I can adjust my comments to match its expectations. Also I'm pretty sure I must have broken it or something is going on in emacs lsp as it stops doing anything.
sigjuice 6y ago
What are the large programs written in bash that need these sorts of developer tools?
- cmckn 6y ago
  Funny you should ask: https://news.ycombinator.com/item?id=26661223 https://news.ycombinator.com/item?id=26661223
thedracle 6y ago
I have used this for years, and I have it mapped to copy into the clipboard on the various OSes I use it on. I especially like the vim like keybindings for visually selecting text blocks (although some things don't quite work the same).
- gkfasdfasdf 6y ago
  What are you talking about? This is a language server, it doesn't have a UI.
- nnadams 6y ago
  Did you mean to add this comment to the nearby "tmux lets you select and copy text with you keyboard" post?

224 points by ducktective 6y ago

I clicked through to the point of skimming the documentation for tree-sitter before giving up on understanding this quickly. There are too many components that I haven’t seen for me to extrapolate out and get to what this does in general terms. Could anyone with more knowledge please explain what this is and how one might utilize it? Fwiw, I’m deeply familiar with Bash; I just don’t recognize the rest.

sabellito 6y ago
Language Servers are pieces of software that implement IDE-like features (like go to definition, find usages, call-hierarchy, rename method, etc) for a given language in an editor-agnostic way. With that, any editor that supports Language Servers can use those to provide better support to a language without implementing any details. In this case, you can see some of the supported editors in the README itself: https://github.com/bash-lsp/bash-language-server#clients https://github.com/bash-lsp/bash-language-server#clients
- benatkin 6y ago
  It doesn't seem editor agnostic to me. It seems geared towards vscode. The idea is also not new - python has had docstrings since the 90s. They never thought to show the full definition on hover or autocomplete, probably because it's noise most of the time, but a lot of people seem to like it.
zeusk 6y ago
LSP is a protocol for IDE/editors to analyze code files and provide functionality like intelligible code search (definition, references etc)
- benatkin 6y ago
  Arguably a protocol for Visual Studio Code to...
  - chusk3 6y ago
    That's simply not true; there are LSP client implementations/integrations for vim, neovim, emacs, sublime text, web environments like gitpod.io, Eclipse IDE (via Theia IDE), Jetbrains supports it in their IDEs, and Visual Studio even has some level of support for it. LSP is _the_ way to write IDE integrations in the modern era. (I maintain LSP tooling for F# and actively support at least half of the editors above)
    - deleted 6y ago
      [deleted]
    - benatkin 6y ago
      It's neither true nor false, it's an opinion. Sure "LSP" has support built in or tacked on (as plugins), mostly tacked on, to other editors. Nobody is required to assume TypeScript docs for a supposedly language-agnostic protocol, or that particular flavor of JSON-RPC, or JSON-RPC, or even JSON. And the pill I don't want to swallow, that people using LSP tend to swallow, is getting full definitions with autocomplete, or hover. Most of the time I prefer to just see completions when I autocomplete, not full definitions. It is clutter.
      - chusk3 6y ago
        I'm not at all sure what you mean by 'typescript docs' in your comment. The protocol for things like tooltips/signature completion literally just says 'put arbitrary markdown here'. It doesn't proscribe the structure of the text the LSP author decides to use. There are also many different display/view methods that more sophisticated LSP implementations can implement. In my own LSP, we have different 'views' of the signatures/types/docs for * hovers * signature completion * detailed type-level embedded docs in a separate pane to name a few. It's entirely customizable.
deleted 6y ago
[deleted]
adonovan 6y ago
Language Server Protocol (LSP) is a standard protocol for "plain old" editors (clients) to make RPCs to local processes that understand the syntax, references, and types of a particular programming language (servers). This reduces the work to support M servers and N clients to M+N, whereas the traditional monolithic approach required M*N integrations. This particular project adds a server for Bash support.
JoBrad 6y ago
To add to the other comments, VSCode docs has a good overview of the motivation and usage of a Language Server. https://code.visualstudio.com/api/language-extensions/language-server-extension-guide https://code.visualstudio.com/api/language-extensions/langua...
widdershins 6y ago
The other comments explained what LSP is - I'll explain what tree-sitter is. It's a clever parser that is very fast when it comes to reparsing a slightly changed file (it's 'incremental'). It's also very good at handling errors and continuing to parse your file. You write a grammar in json and it gets compiled to a shared library via C.

brendanfalk 6y ago

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.

usbline 6y ago

Development tools like this with an obscene amount of dependencies, not to mention multi-language dependencies, is extremely worrying and irresponsible for the future of software development. Especially since they're not even native to bash's environment! If you would have told me 5 years ago I'd need to install node and typescript in order to get auto completion for bash, I'd have called you crazy. Yet here we are.

nicoburns 6y ago
What do you expect a bash language server to be written in? Bash?
- mdip 6y ago
  You said it, sarcastically, but that didn't mean I didn't think it. At first blush it sounds a little crazy, but the more I think about it... Consider my problem: I use `zsh` and have created, collected and organized a large number of completions which I synchronize among several workstations. It frustrates me to no end that I cannot take advantage of these completions in very many other convenient places, like VSCode[0]. The benefit of writing it in `zsh` (I can't speak for bash) is that seems like it'd be pretty simple to wire up the LSB as a sort of "completions proxy" that simply takes the inputs, passes them to a completion script, parses the output and formats it in the appropriate JSON response. The utility of being able to have a single script (or set of scripts) that I can include in my shared profile directory which will run and handle a `zsh` LSB implementation on-demand (i.e. doesn't need installing, sits in my scripts directory and runs everywhere) would be a huge feature. This will speak to my ignorance, but can you host a web server (in a manner that can be consumed) from just bash and a lean environment[1]? Could you host an LSP without one (i.e. is there enough to use a socket and would it be enough to point it at the right place/scheme?). I believe there are `zsh` extensions which can facilitate some/all of this, but I'm not sure if it would work out of the box. The downside to developing it in `zsh`, other than the language itself[2] is performance. Both of those, assuming "the hosting/serving" can be handled easily, don't represent big problems, maybe they are. But performance and the language should be up to what remains outside of that. [0] I had `nvim` set up correctly, once to work with completion scripts and was able to translate that into VSCode doing the same, about two years ago. I'm still not fully convinced I didn't just dream this up because the few times I've looked into it, since, I've gotten nowhere (admittedly, I've put little effort into researching). [1] I'm thinking 'busybox', minimal gnu-related things, ideally requiring as little as possible beyond a relatively recent version of `bash` so that "if it's got bash, I can use it". [2] I use `zsh` because it's easier for me to write things in it than `bash`, and at times it can be fun. But there's a reason we don't build solutions using it. [3] Everything's a string...

gkfasdfasdf 6y ago

I have been using this for a year or so and it is awesome. I use with neovim + LanguageClient-neovim. I don't really understand why people are complaining about the dependencies - on macos just brew install node@14 and npm install -g bash-language-server. Check for updates occasionally via npm outdated -g. I really have no idea what the dependencies are other than node and nor do I care - its just another app on my system.

prussian 6y ago

Kind of cute. Jumped around with xref and found callers for functions, but can't really imagine this to be useful unless you're as crazy as I am or also responsible to insane number of these _things_. Not sure what qualifies as doc strings, I discovered you have to use two hashes for multiple lines. More documentation on that might be helpful then I can adjust my comments to match its expectations. Also I'm pretty sure I must have broken it or something is going on in emacs lsp as it stops doing anything.

sigjuice 6y ago

What are the large programs written in bash that need these sorts of developer tools?

cmckn 6y ago
Funny you should ask: https://news.ycombinator.com/item?id=26661223 https://news.ycombinator.com/item?id=26661223

thedracle 6y ago

I have used this for years, and I have it mapped to copy into the clipboard on the various OSes I use it on. I especially like the vim like keybindings for visually selecting text blocks (although some things don't quite work the same).

gkfasdfasdf 6y ago
What are you talking about? This is a language server, it doesn't have a UI.
nnadams 6y ago
Did you mean to add this comment to the nearby "tmux lets you select and copy text with you keyboard" post?