Feature request: Support overriding the current shell dialect

[Ionic]

This issue is akin to #664, but not a duplicate.

Quite often, I find myself having to write scripts that re-execute themselves with the proper interpreter, because portability is a real pain.

The most common denominator is /bin/sh, which exists on virtually any UNIX-like system. Everything else, including env, can live in different places, so is not a good starting point.

A feature that allows me to write code like this would immensely help:

#!/bin/sh
# shellcheck shell=sh

[ 'reexec' != "${1}" ] && exec '--' '/opt/secret/location/special_bash' '--' "${0}" 'reexec' "${@}"

# From this point on, we can safely use bash features.

# shellcheck shell=bash
[[ 'reexec' != "${1}" ]] && exit '1'

Crucially, multiple shell directives should be supported, but their scope not limited to functions, commands or the whole file, but up to the next shell directive (if any).

(N.B.: an ugly workaround is to just set the shell dialect to sh and use global disable directives for all non-POSIX-sh features, but that quickly gets annoying. It's also technically wrong, since warnings for non-POSIX-sh features are legit up until the exec point.

A different workaround is to split the code up into two files - a POSIX sh loader and the actual bash code. But that, likewise, is inconvenient.)

[koalaman]

I see the problem, though it's quite niche compared to the refactoring it would take. You can leave the issue open, but I think your best bet is to specify shell=bash and just manually vet the code up until the re-execution line. (Also note that shellcheck -s sh will override both the shebang and the directive in case you'd want to kludge something with head/sed | shellcheck -s sh -)

[Ionic]

Thanks. Yeah, I figure that this would require quite some refactoring in the parser. I've never gotten warm with Haskell at all, even though I had to use it as part of my studies, so I cannot help in providing patches either.

It would still be nice to have this feature eventually, but probably as the lowest priority one can think of.