Husky 4.x: Usage of SHELL environment variable can cause unexpected behavior

[barretron]

I'm not sure if this is an actual bug or if this is just something that might need to be documented, but I was running into problems upgrading to Husky 4.x and finally figured out what the issue was.

Background
My company sets /bin/tcsh as the default shell, but I override this in the user settings of apps like VSCode and Terminal.app to use /bin/zsh. As a result, Husky uses /bin/tcsh to run its scripts since the SHELL environment variable remains unchanged. However, tcsh behaves differently from sh in that it uses a login shell with -c unless the -f flag is set. Unfortunately, my company's standard login script (.cshrc) is destructive and resets the PATH. This results in Husky erroring out due to not being able to find lint-staged. Husky <= 3.x does not have this issue.

Workaround
Exporting a different SHELL environment variable in ~/.huskyrc does the trick:

# ~/.huskyrc
export SHELL=/bin/sh

OS: macOS 10.14.6
Terminal: VSCode integrated terminal
Shell: /bin/zsh

Example output (without workaround):

❯ HUSKY_DEBUG=1 git commit -m "Test commit"
husky:debug husky v4.2.3 - pre-commit
husky:debug Current working directory is /Users/barretron/Documents/projects/co/app/packages/front-end
husky:debug source ~/.huskyrc
husky > pre-commit (node v12.4.0)
lint-staged: Command not found.
husky > pre-commit hook failed (add --no-verify to bypass)
husky:debug yarn run --silent husky-run exited with 1 exit code

[frantic1048]

An elvish user here. After upgrading to 4.0, I got Parse error: unexpected rune '&' from elvish because hook script uses '&&' operator which only bash like shell supports.

I have to wrap the whole hook script with sh -c to force the script is running in a specific shell.
And it is very unreliable because husky is calling elvish -c 'sh -c <HOOK STUFF>' (which assumes elvish has a '-c' option which accepts command string.) on first.

[typicode]

Hi @barretron,

Thanks for raising this issue. Just published a new version 4.2.4. It should always be sh now (like in v3).