Allow specifying color= in shellcheckrc (closes #2350)

[oliv3r]

To be able to set the color option in the config file (detection in GitLab CI fails for example) is useful when using template shellcheck containers for one. Secondly, storing config in the repo is also a thing :)

Sadly, I got a bit overconfident and got lost very quickly. I never seen haskell before so there's a learning curve required I suppose. I did make a start hopefully for whomever can pick it up :)

[koalaman]

It's not entirely straight forward because .shellcheckrc files are per-file while the formatter options are per invocation.

For example, you can do

echo "disable=SC2034 # Don't warn about unused variables" > lib/.shellcheckrc
echo "disable=SC2016 # I know how to use single quotes" > bin/.shellcheckrc

and then shellcheck */*.sh will apply the correct rules to the correct files.

The color option currently does not support being applied to some files but not others, and if you were to extend this to wiki-link-count I'm not sure what it would mean for one file to say 0 and another to say 5.

[oliv3r]

Alternatively, making sure auto 'always' works is an option :p

but in seriousness, I do like having options stored in a per-repo level. I think it should just traverse in the tree though, right? so global, trumps user, trumps root, trumps folder setting. So if you have it in your local rc, but not anywhere in the repo; you get it.

I suppose one could argue on the directory vs root level; it could be that 'note, some settings, regardless where they are set, are applied to the repo as a whole, when asking shellcheck to auto-scan for files, if this is undesiresd invoke shellcheck on a 'per file' basis' and there, it should favor local settings over root settings?

[Alhadis]

IMHO, this really belongs in an environment variable (FORCE_COLOR=1 and NO_COLOR=1). It's easier to forcefully enable/disable colour support for a process this way, and users typically do so cognisant of where/how output is being rendered; e.g., an Emacs buffer or pager like less(1) will want consistent colouration behaviour regardless of a project's local configuration.