paxsali
commented
1 day ago I just had an idea.
Instead of a separate file for the errors, maybe it would be sufficient to add new command line options for shellcheck to list all the errors programmatically.
Example (this is a mockup cmdline):
# to simple print a brief overview of checks (no input files required)
shellcheck --list-checks
# SC2162 (info): read without -r will mangle backslashes.
# ...
# to only list the (valid) check IDs (for the current version of shellcheck, no input files required)
shellcheck --list-checks-only-ids
# SCxxxx
# SCxxxx
# SCxxxx
# etc.
# to view information (warning message or suggestion) of one or more particular checks (no input files required)
shellcheck --info=SC2119
shellcheck --info='SC2119-SC2123'the format options -f FORMAT can still apply to change the output of above mockup cmdline options.
I like this idea better than a separate file, bth, however the two things are independent.
Hello,
I'd like to programmatically work with the shellcheck errors and for that I'm looking for a data file that contains all the errors.
I was expecting to find either a json or yml file or similar in the repo, but after checking out the repo and grepping, there doesn't seem to be such a thing.
grepping for specific errors mostly gives hits in the CHANGELOG.md.
It appears to me as if the the errors are hard coded in the source, instead of managed separately.
If you omit the "SC" prefix and grep for just the error ids, then you find mostly hits in Analytics.hs.
My main motivation is to create a template file for yasnippet / Emacs.
It's still possible and I'll certainly manage to somehow parse the haskell code (not a HS programmer myself) and get what I want.
However, I was rather surprised to see how the errors and the logic are entangled and it doesn't seem right to me.
I don't know how others feel about this, or if people think this is a problem at all, but IMHO I think a separation of code and data makes sense.
It should be the build processes' job to marry the error database with the final binary, not the programmer's or compiler's job to deal with this (by literal hard-coding).
I'm just leaving this issue for discussion.
Bye.