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.

[ferdnyc]

I agree with both @koalaman and @Alhadis.

@koalaman makes an excellent point about the .shellcheckrc files. They're not appropriate for this type of per-invocation preferences / user default options, since they're locally scoped. If flags like --color and --wiki-link-count were going to be controllable via a configuration file, I think it should be a new, single-instance preferences file, with a default location like $HOME/.config/shellcheck.conf (though perhaps overridable via shellcheck --config=<path>). That file would be completely separate from the .shellcheckrc files, though.

HOWEVER, in terms of color, specifically, @Alhadis is right that supporting FORCE_COLOR and NO_COLOR environment variables would be a simpler and more widely supported / understood solution. Respecting those envvars would likely make a file-based config for --color unnecessary.

...And the other side of the coin is, even if a file-based color= option is supported, it's STILL in the best interests of shellcheck to also respect the (becoming-)standard environment variables for controlling color output.

The color-control envvars don't solve wiki-link-count & etc., of course. Though, an additional, generic envvar, something like SHELLCHECK_ARGS, could. e.g.:

# These three lines of shell input...
NO_COLOR=1
SHELLCHECK_ARGS="--format=checkstyle --wiki-link-count=2"
shellcheck -e SC1011 .

# Would have the exact same effect as this command...
shellcheck --color=never --format=checkstyle --wiki-link-count=2 \
  -e SC1011 .