Ask HN: Let's build Checkstyle for Bash?

59 点作者 a-t-0大约 3 年前

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: <a href="https://github.com/koalaman/shellcheck" rel="nofollow">https://github.com/koalaman/shellcheck</a>From Asynchronous Lint Engine (ALE): <a href="https://github.com/dense-analysis/ale/blob/master/supported-tools.md" rel="nofollow">https://github.com/dense-analysis/ale/blob/master/supported-...</a>- bashate: <a href="https://github.com/openstack/bashate" rel="nofollow">https://github.com/openstack/bashate</a>- cspell: <a href="https://github.com/streetsidesoftware/cspell/tree/main/packages/cspell" rel="nofollow">https://github.com/streetsidesoftware/cspell/tree/main/packa...</a>- Bash Language Server: <a href="https://github.com/bash-lsp/bash-language-server" rel="nofollow">https://github.com/bash-lsp/bash-language-server</a>- shell -n flag: <a href="https://www.gnu.org/software/bash/manual/bash.html#index-set" rel="nofollow">https://www.gnu.org/software/bash/manual/bash.html#index-set</a>- sh(shfmt): <a href="https://github.com/mvdan/sh" rel="nofollow">https://github.com/mvdan/sh</a>- shdoc: <a href="https://github.com/reconquest/shdoc" rel="nofollow">https://github.com/reconquest/shdoc</a>From this stack post [1]:- checkbashisms: <a href="http://man.he.net/man1/checkbashisms" rel="nofollow">http://man.he.net/man1/checkbashisms</a>- shlint: <a href="https://github.com/duggan/shlint" rel="nofollow">https://github.com/duggan/shlint</a> (archived)Prettier: <a href="https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode" rel="nofollow">https://marketplace.visualstudio.com/items?itemName=esbenp.p...</a>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:<pre><code> 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. </code></pre> 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]: <a href="https://google.github.io/styleguide/shellguide.html" rel="nofollow">https://google.github.io/styleguide/shellguide.html</a>[1]: <a href="https://stackoverflow.com/questions/3668665/is-there-a-static-analysis-tool-like-lint-or-perlcritic-for-shell-scripts" rel="nofollow">https://stackoverflow.com/questions/3668665/is-there-a-stati...</a>[2]: <a href="https://github.com/TruCol/checkstyle-for-bash" rel="nofollow">https://github.com/TruCol/checkstyle-for-bash</a>

9 条评论

derefr大约 3 年前

I've always been confused that in ${current_year} people are still directly writing huge + complex shell scripts.Compare/contrast Javascript, another language we're "stuck with": while you can still directly write it, many people don't, instead using transpilers to target Javascript as an "object code" from some other, stricter language (e.g. TypeScript, ClojureScript, arbitrary native languages via Emscripten / WASM compiler targets, etc.) Via these languages/compilers, everybody who wants compile-time strictness can have it. And you can even get runtime strictness that Javascript itself doesn't have, as the checked semantics of these languages will often be "lowered" into the resulting Javascript by generating explicit assertions (usually this is on by default, unless you ask for an optimized build.) But the output is still just "Javascript", that any browser can run.Why hasn't a similar thing happened for POSIX-standard Bourne shell? Why are we seemingly "satisfied" with writing + maintaining 5000-line install.sh scripts in our codebases, with a bunch of extra mental overhead / tooling required to keep the code sane and clean; when we could just be writing in a sane and clean language to begin with?Is it just that nobody's bothered to create such a language/compiler? Do I need to be the one to step up, here?

评论 #30408167 未加载

评论 #30407679 未加载

评论 #30408414 未加载

评论 #30416248 未加载

评论 #30410221 未加载

评论 #30416136 未加载

nickjj大约 3 年前

2 things I'd love to see in a checker would be:Warn me when I'm using -h instead of --help. When writing persisted scripts it's often more descriptive and self documenting to use long form flags[0] when a tool gives you both options.Warn me when I mix using "-p 8000:8000" and "-p=8000:8000". I know it's technically not possible to give a definitive answer here because supporting spaces vs equals comes down to the CLI tool itself but you can pick up when you mix the 2 styles and leave it up to the script author to pick a style and stick with it when possible.I do a lot of shell scripting in my day to day (ops, etc.) and it's always a manual process to give feedback on code reviews when others contribute patches or introduce new scripts.[0]: <a href="https://nickjanetakis.com/blog/when-to-use-long-word-or-short-letter-command-line-flags" rel="nofollow">https://nickjanetakis.com/blog/when-to-use-long-word-or-shor...</a>

评论 #30405894 未加载

bashhacker大约 3 年前

Take a look at shfmt and shdoc. One is an auto formatter, the other does autodocs. I wouldn't invent yet another docstring format. It's already been done. Just check compliance with an existing format.

评论 #30405561 未加载

评论 #30405712 未加载

Etheryte大约 3 年前

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

评论 #30405664 未加载

评论 #30405463 未加载

评论 #30408112 未加载

评论 #30405403 未加载

ancientsofmumu大约 3 年前

Google's styleguide has incorrect bash being used, they are using string comparison operators for numeric comparisons (see the various `$? != 0` and $PIPESTATUS).<pre><code> [[ -1 -eq 0-1 ]] && echo true || echo false [[ -1 == 0-1 ]] && echo true || echo false </code></pre> <a href="https://www.gnu.org/software/bash/manual/html_node/Bash-Conditional-Expressions.html" rel="nofollow">https://www.gnu.org/software/bash/manual/html_node/Bash-Cond...</a>

评论 #30406067 未加载

hyperupcall大约 3 年前

This is a neat idea, but I'm not sure I see the need for this specific tool. Shellcheck covers essentially all the errors that are mentioned in the Google Style Guide so I'd just be using that instead.And as the Guide itself, it is mostly OK, but there are a few things I really don't like. For example:- Whatever doc format they use is not as nice to use as shdoc. Namely, you don't have to add the spaces to your comment to make it formatted properly- The 'no tabs' thing is pretty bullshit - Bash is literally the perfect language to use tabs and their "Whatever you do, don’t use tabs" comment really kills me- I don't like their recommendation of using `[[`. Only using `[[` for stuff like regex and glob matching makes it much easier to paste code between Bash and POSIX sh.There are also a few things they forgot to mention, like the lastpipe` shopt option when talking about piping while loops. And maybe it would be nice to recommend using local like `local var=`. But I guess this guide is meant more for new people that don't know all the pitfalls and stuffBut I think I agree there is some need for a more extensible linter. I've been eyeing the Bash LSP, which is based off the Bash Tree Sitter parser, but that has quite a few bugs with parsing that I've been meaning to send PR's for.I wonder if `shfmt` has gotten better since I used it. A few years ago, it was quite buggy with prepending extra whitespace whenever I formatted the file

hutrdvnj大约 3 年前

If your problem can be solved neatly with some combination of existing shell utilities, and you just need a bit of glue to join them together, bash is great.The huge weakness of bash is the data mangling that is more complicated than a relatively simple per-row transformation. Splitting, joining, sorting, min/max of data structures like arrays, lists and trees are trivial in python, not so in bash. If it's not trivially seddable, and awk doesn't help either because you have to rearrange tree like structures, you are about to experience a massive pain, because it's out of scope of even expertly used associative arrays and you will find yourself reinventing the wheel hard using pretty basic tools.TLDR; As soon as you need to use something more complex than a for loop, switch to Python.

latchkey大约 3 年前

Intellij has a builtin plugin that integrates with ExplainShell, Shfmt, ShellCheck.

eternityforest大约 3 年前

I think we should really be working to deprecate large bash scripts. If you write enough to care about code quality you might want to just use Python.I'd say look at things like Oil(Is that project ever going to be the next big thing like it claims?).... but writing large scripts in ANY shell doesn't seem like the best plan.What about an Ansible linter? Do those exist? I'm starting to suspect Ansible might be a better choice for a lot of what people do with bash, even if you are running om a desktop.

评论 #30405562 未加载

评论 #30405672 未加载

评论 #30405473 未加载

评论 #30405514 未加载

评论 #30406166 未加载