Using the SHELL environment variable to determine the command
interpreter was problematic because the variable signals the shell that
is being used, not the shell that is intended to run scripts in a
project. That said, for systems that do not have have an executable on
their path named sh, or if sh is less desirable, there needs to be a
way to specify what should be used instead.
The solution here is to allow users to specify their own interpreter and
the flags needed to invoke it. This effectively removes the requirement
for an interpreter to match the following pattern:
${SHELL} -c "..."
The range of supported interpreters is therefore expanded to include
anything that can run an arbitrary script passed as a string, such as
node or ruby, whether or not they happen to have a -c flag.
This setting may only be specified at the file level rather than the
task level. While there may be semantics that make sense to allow for
more granular specification of the interpreter, those are not currently
clear to me, and I don't necessarily know that they are worth
supporting.
This change also unifies commands run during when or option clauses
so that they respect the interpreter setting the same way that a command
does.
rliebz
commented
4 years ago
Rework command interpreters
Using the
SHELLenvironment variable to determine the command interpreter was problematic because the variable signals the shell that is being used, not the shell that is intended to run scripts in a project. That said, for systems that do not have have an executable on their path namedsh, or ifshis less desirable, there needs to be a way to specify what should be used instead.The solution here is to allow users to specify their own interpreter and the flags needed to invoke it. This effectively removes the requirement for an interpreter to match the following pattern:
The range of supported interpreters is therefore expanded to include anything that can run an arbitrary script passed as a string, such as node or ruby, whether or not they happen to have a
-cflag.This setting may only be specified at the file level rather than the task level. While there may be semantics that make sense to allow for more granular specification of the interpreter, those are not currently clear to me, and I don't necessarily know that they are worth supporting.
This change also unifies commands run during
whenoroptionclauses so that they respect the interpreter setting the same way that acommanddoes.Resolves: #72