It would be good to have it defined (and coded), what shellcheck returns when it finds problems, so it can be queried in a script.
Like maybe 0: no problems, 1: suggestions (green) 2: warnings (yellow), -1: errors (red).
-1: errors (red)
Nope. Return codes are limited to 0~255 (an unsigned 8-bit integer). Which shellcheck would tell you.
Ok, I could live with errors 3 :)
Good point! Error codes have been defined for a while (and used by e.g. syntastic). As of 3b36c2c they are documented in the man page.
They don't differentiate between style/warning/error type codes, but these are kind of fluid categories anyways.
I would have liked to have seen this, so that I could do a git pre-commit phase and check that there aren't any "real" errors. I rarely write a shell script, that has no warnings though :) An alternative would be to have a (growing) list of SC codes to ignore, that one could query. e.g. Give me all SCs < red. But I still think a return code would be more convenient.
For a precommit, you can do this today with shellcheck -f json files... | jq '.[].level' | grep error
In the near future, shellcheck is likely to get a verbosity option where you can choose from "nitpick on any minor potential issue" to "only if I'm about to steam someone".
Nice, thx for the idea with json.
I tried it in real life, result: it works; but now I don't see the reason WHY it failed. So I have to rerun it, which is clumsy IMO.
In a Makefile I "compile" my shell scripts with a rule like this now:
%.chk: %.sh
- shellcheck $(SHELLFLAGS) $<
(shellcheck -f json $(SHELLFLAGS) $< | jq '.[].level' | grep error > /dev/null ) && exit 1 || touch $@
In the near future, shellcheck is likely to get a verbosity option where you can choose...
@koalaman Just wondering if this was still on the roadmap :D
It definitely is, I was just too optimistic about the timeline
Most helpful comment
It definitely is, I was just too optimistic about the timeline