Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directly re-execute the current script #1111

Closed
wants to merge 1 commit into from

Conversation

petekeen-cf
Copy link

@petekeen-cf petekeen-cf commented Mar 2, 2022

The current husky.sh re-executes the current script with sh -e, completely ignoring whatever shebang line is in the script. This causes failures when scripts are expecting bash-specific features but /bin/sh is linked to something that is not bash (ex: /bin/sh is dash on Ubuntu).

This change makes it re-execute using env instead which will just run the script. This is safe because by definition git hooks have to be executable:

Hooks that don’t have the executable bit set are ignored.

Fixes #971.

@typicode
Copy link
Owner

typicode commented Mar 3, 2022

Hi,

Thanks for the PR :)
Changing to env changes husky current behavior, which is to exit on the first failing command.

For example:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

foo
bar
baz

Will output with env:

.husky/pre-commit: line 4: foo: command not found
.husky/pre-commit: line 5: bar: command not found
.husky/pre-commit: line 6: baz: command not found
husky - pre-commit hook exited with code 127 (error)

vs with sh -e:

.husky/pre-commit: line 4: foo: command not found
husky - pre-commit hook exited with code 127 (error)

That said this PR was merged recently and makes use of env I don't know if that can help:
#1051

It's not yet released though.

@petekeen-cf
Copy link
Author

I saw that PR but I don't think it solves this problem because those #! lines are entirely ignored on re-exec. They never get read because sh -e is executing the file as if it were a shell script. The kernel (or equivalent process in macOS) is what actually looks at the #! line and decides what to run.

That said, I see where you're coming from with this behavior. I agree that it's nice to fail fast and to attempt to force that behavior on script authors. I'm just in an environment where we want our scripts to use non-POSIX bashisms like set -o pipefail, but re-executing with sh makes those fail on platforms like Ubuntu where sh is linked to dash.

I'll go ahead and close this out since it's not desired behavior.

@petekeen-cf petekeen-cf closed this Mar 3, 2022
@typicode
Copy link
Owner

typicode commented Mar 3, 2022

If husky's script gets in your way or your team, feel free to modify/commit it locally or simply remove it. The script may be useful in the case of an Open Source project where you don't know about other people environments, but if it's for a private project where you have more control, it can makes sense to not use it.

Alternatively, if you want to keep it and use bash, you can also do:

# .husky/pre-commit
#!/usr/bin/env sh
. "$(dirname "$0")/_/husky.sh"

bash your_bash_script

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support arbitrary shells for hook scripts
3 participants