7 ms·
Ask HN: Let's build Checkstyle for Bash?
After working with Bash and Shellcheck for a few months, I noticed I could improve my code quality by making it compliant with the Shell Style Guide by Google [0]. While working on that, I thought some aspects of this Shell style guide can be verified automatically, granted some assumptions/opinions are formed. So I looked around for linting tools and autoformatters for Bash:
Shellcheck: https://github.com/koalaman/shellcheck https://github.com/koalaman/shellcheck
From Asynchronous Lint Engine (ALE): https://github.com/dense-analysis/ale/blob/master/supported-tools.md https://github.com/dense-analysis/ale/blob/master/supported-...
- bashate: https://github.com/openstack/bashate https://github.com/openstack/bashate
- cspell: https://github.com/streetsidesoftware/cspell/tree/main/packages/cspell https://github.com/streetsidesoftware/cspell/tree/main/packa...
- Bash Language Server: https://github.com/bash-lsp/bash-language-server https://github.com/bash-lsp/bash-language-server
- shell -n flag: https://www.gnu.org/software/bash/manual/bash.html#index-set https://www.gnu.org/software/bash/manual/bash.html#index-set
- sh(shfmt): https://github.com/mvdan/sh https://github.com/mvdan/sh
- shdoc: https://github.com/reconquest/shdoc https://github.com/reconquest/shdoc
From this stack post [1]:
- checkbashisms: http://man.he.net/man1/checkbashisms http://man.he.net/man1/checkbashisms
- shlint: https://github.com/duggan/shlint https://github.com/duggan/shlint (archived)
Prettier: https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode https://marketplace.visualstudio.com/items?itemName=esbenp.p...
Within all these linters and auto-formatters I did not find checks that enforce, for example, the Function Comments of the Shell Style Guide by Google:
All function comments should describe the intended API behaviour using:
Description of the function.
Globals: List of global variables used and modified.
Arguments: Arguments taken.
Outputs: Output to STDOUT or STDERR.
Returns: Returned values other than the default exit status of the last command run.
Hence, I thought we could make a Bash linting tool that verifies compliance with the Shell Style Guide by Google. To do so, a brief start was made here [2]. It identifies/lists elements in that style guide that may be verified automatically. Since Bash has been around longer than me, I think there may be some people better suited for the development of this enhanced linter. Hence, I thought it might be wise, for impact and usability, to share this idea here.
What do you say, HN?
[0]: https://google.github.io/styleguide/shellguide.html https://google.github.io/styleguide/shellguide.html
[1]: https://stackoverflow.com/questions/3668665/is-there-a-static-analysis-tool-like-lint-or-perlcritic-for-shell-scripts https://stackoverflow.com/questions/3668665/is-there-a-stati...
[2]: https://github.com/TruCol/checkstyle-for-bash https://github.com/TruCol/checkstyle-for-bash
- Etheryte 5y agoOut of pure curiosity, in what context do you write sufficient amounts of Bash scripts that style checking is a worry that needs your attention? While I also write small one-offs or bootstrap scripts here and there, in most cases it's my experience that developers opt for other languages for anything beyond small snippets.
- zinekeller 5y agoLargely same sentiment. Pure POSIX shell scripts for embedded systems, sure, but I'm not sure if there is a niche that requires Bash scripting. Not discouraging these efforts of course but I'm not sure that it'll be worth it.
- amelius 5y agoThe niche is installer scripts. Because there is one certainty: Bash is available everywhere.
- zinekeller 5y ago> Bash is available everywhere POSIX mistake number 1: Bash isn't available everywhere, even when restricted to Linux. Even Debian avoids bash for a good reason (Bash is slower than most POSIX shell implementations), although it's installed by default for convenience.
- drran 5y ago> Even [on] Debian ... it's installed by default for convenience. :-/
- fjorde 5y agozinekeller's point notwithstanding, i agree that "installer scripts" is really the last necessary domain of the bash script. If you need a (semi)portable script to get `python` to run your python script, you can't use python, obviously. Things like docker images and nix builds are sold as huge improvements on this chicken-egg problem, at least from a "keep it all in one language" perspective, but only if you consider a docker script (mostly bash) or a nix config truly not the same thing as a shell script that more or less initiates the same environment. docker/nix abstraction layers have advantages but aren't always as portable as a shell script. If you need a docker engine, I think you'll still need a bash script to install that... Nix is possibly even more "single command", often just a curl if i'm not mistaken, but still requires config and shipping a build somewhere, and you still need to run the `curl` command in a shell somehow. i don't see how "just use python" will ever fix the init chicken-egg problem.