where is the errors database in the github repo?

[paxsali]

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.

[paxsali]

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.

[koalaman]

It's a good suggestion and today this kind of code would likely have been written via some form of templating. Not only would this allow enumerating warnings and i18n, but it would improve features like --include=CODE1,CODE2.. which currently invokes ALL checks and just throws out results not in the list.

It would be a significant overhaul touching a lot of code without much visible impact though, so it's unlikely to make it onto a roadmap.