ShellCheck: A static analysis tool for shell scripts (github.com)

yeah, for integration with coc-nvim, take a look at this github comment: https://github.com/meatwallace/dotfiles/issues/129#issuecomm...

There is also a LSP at : https://github.com/bash-lsp/bash-language-server

Rust Compiler Error Index

https://doc.rust-lang.org/error-index.html

Yeah, C# compilers do. Easily Googleable error code to further explain it.

I recall working with AngularJS, which output error messages that had links, which opened the documentation with bits from your stack trace filled in.

It was a while ago and seemed a bit gimmicky, but i really enjoyed the ability to see what could be done about an error by opening a web page (without having to manually dig through StackOverflow or other sites).

Now, if we'd get a development framework that'd couple documentation like that, with user generated comments (like PHP has, for example see the bottom of https://www.php.net/manual/en/function.strcmp.php ), then i think the developer experience would improve a bunch!

Who knows, maybe even allow users to contribute possible fixes and allow those as autocomplete solutions and you've just improved on what tools like Codota do a whole bunch!

Hadolint is another. It's built atop shellcheck.

https://github.com/hadolint/hadolint

find-sec-bugs does that. It's used by, for example, SonarQube.

See https://github.com/find-sec-bugs/find-sec-bugs/blob/master/f...

Error Prone does this: https://errorprone.info/bugpatterns

Errorprone (java compiler plug-in) has this as does NullAway (an errorprone plug-in)

I agree that it’s really handy, especially when implementing the check in a CI pipeline with lots of developers.

Many of the JS linters do as well (eslint, etc).

SQLAlchemy also does something similar. It points to relevant SQLAlchemy page for more information about the error.

Dart's static analyzer & lint rules: https://dart-lang.github.io/linter/lints/

Each rule has its own url. Tool therefore easily gives you a link.

If you're building a REST API, make sure to check out RFC7807 ( https://tools.ietf.org/html/rfc7807 ) , which recommends doing exactly this. Giving each error a type, which is a resolvable URI.

zpool status

Newer versions of GCC have clickable (using terminal escape sequences) warning flags in the output that link to the corresponding documentation.

Staticcheck for Go kind of does something similar in that it outputs Googleable error codes, but doesn't actually print a link to the pages. It's also included as part of golangci-lint.

https://staticcheck.io/docs/checks

It is also a quite nice tool for checking the POSIX compatibility of shell scripts. I find it very useful when working on Solaris or some other UNIX that does not use Bash by default.

haskell forbidding people to leave fragile bash to learn babashka !

Same. Few years ago I started a little list of linters. Just kept adding tools and the list is huge now thanks to lots of contributors. https://github.com/analysis-tools-dev/static-analysis Still love adding new linters there when I cross their path. :)

I believe they are near-essential for properly learning a language.

I can credit Resharper for a large part of my proficiency in C# for example.

Unless you're composing very rich commands, likely not much will show up. It exceeds at finding things like interpolation gotchas, bad loop control, etc. Much more structural than just one off commands (though would likely bug about a bunch of useless `cat`s when you can use redirect operators instead (i.e. `cat foo.txt | grep` is an antipattern according to shellcheck)

shellcheck-repl: Validation of Shell Commands Before Evaluation

https://github.com/HenrikBengtsson/shellcheck-repl

This tool validates your commands at the Bash prompt using ShellCheck and refuses to evaluate them if there's a mistake. It ignores a set of rules that doesn't play well with oneliners.

(Disclaimer: I'm one of the authors)

It is actually good enough to be here that often. More often, even.

It's like in this xkcd. It's always new to somebody.

https://xkcd.com/1053/

And 23 more for https://news.ycombinator.com/from?site=shellcheck.net :)

Not once did I see it till now, its not like people are here 365 days or new people dont join.

I find it helps if you have a hard rewrite rule. I really love the convenience of shell scripts for small scripts, but as soon as I have one that crosses 100 lines I rewrite it in python. The python version is a bit less convenient for spawning processes and piping them together, but it's so much more maintainable that you can scale it up to quite a bit larger without as much worry. 100 lines is a nice size where it doesn't take very long to rewrite, so even though I figure I could get away with a longer shell script without it getting too bad, I'm definitely not going to want to rewrite it once it gets big enough to be a problem.

I went looking through the issue tracker to see if there's an issue about supporting $XDG_CONFIG_HOME and was pleasantly surprised to find out that it seems to already work. So ~/.config/shellcheckrc works just as well as ~/.shellcheckrc

There are quite a few unit-testing frameworks for bash. I wonder, have you reviewed and compared them and came to `shunit2`?

I really like task (http://taskfile.dev/) as a more usable layer on top of mydan/sh. Task is basically make but with a yaml syntax and built-in posix shell interpreter all in a single statically linked executable. It makes building something even on Windows a total breeze.

I much prefer this to the format you were using several months ago :)

shellcheck won't force you to prefer one of the two variants, hence the difference is relatively subtle to a degree that even documentation is not superhelpful either: https://www.oilshell.org/blog/2016/10/12.html

shellcheck will show you many more mistakes that are much more painful your example and also very common.

Deno is definitively an interesting language, but Shell scripting is the gateway to bootstrap so many of your beloved programming languages. If your environment allows it always prefer a proper programming language over shell scripting. Shell scripts are meant for Unix operating system operations, setting few variables, combining certain data-sources, doing filesystem operations, ...

A useful thing with conditionals is shellcheck will warn you not to write [ foo -eq 1 && bar -eq 2 ], but to write [ foo -eq 1 ] && [ bar -eq 2 ] or [[ foo -eq 1 && bar -eq 2 ]].

I do think it would be nice if shellcheck was more opinionated, or if it was possible to create rulesets that have stronger opinions. For example, I would personally like to enforce the use of double bracket conditionals in my scripts, but I know that others prefer the single bracket variety.

Which shebang was your script using?

If it was

  #!/usr/bin/env sh

then shellheck would report

  SC3010: In POSIX sh, [[ ]] is undefined.

.

Those are both valid in bash. If you were using posix sh it would error.

Can you expand on why y'all thought Bash was a natural fit to kick off all your tests?

And talking about tests... I recommend [bats](https://github.com/bats-core/bats-core) for testing! I'm slowly adding tests to my dotfiles using this.

Quality links there. Thanks!