today shellcheck has one big knob to control dialect: the -s option. we'd like to run shellcheck against scripts and say it's the POSIX dialect but with support for local. our options today are not optimal:
--shell=dash, but then silently allow dashisms--shell=bash, but then silently allow bashisms--shell=sh -e SC2039, but then silently allow all undefined thingsit looks like dialect details are sprinkled through out the code base:
] ++ if not isDash then ["local"] else []whenShell [Bash, Dash] $ do -- Ksh allows it, Sh doesn't support localif the dialect details were split out into a data structure (a dict/map), and all the code checked that data structure, it'd be easy to expose those to the command line as people could set specific dialect features directly.
on the other hand, if we consider local a common enough thing, adding a one-off knob for it would be OK too :).
@yetamrra another use case that would be covered by this is defining dialects for projects. for example, linting Gentoo ebuild/eclass files follow a particular set of rules that we'd like to be able to enforce.
SC2039 should really have had a separate error code per issue, that way you could just have ignored that particular one.
Most helpful comment
SC2039 should really have had a separate error code per issue, that way you could just have ignored that particular one.