WSL2 (or Linux?) cannot use regular expressions in "[[ ]]" syntax about husky HOT 15 OPEN

@typicode I believe that, if the script has both execute permission and has a shebang (i.e. starts with #!), then the script should be invoked by itself rather than with sh -e.

This would give users maximum flexibility if they know what they are doing, including having a Python or Node.js script. as opposed to a shell script.

from husky.

On Ubuntu, the default for /usr/bin/sh is to be symlinked to dash.
Please refer to this stackoverflow answer as to why that is.

In dash, neither [[ … ]] nor regex matching are supported.

We now use something like this:

#!/usr/bin/env dash
set -e

BRANCH="$(git rev-parse --abbrev-ref HEAD)"

if echo "$BRANCH" | grep -q -E '([a-z]+/([0-9]+\.){2}[0-9]+.*$)'; then
  echo "branch ✅"
else
  echo "branch 🛑"
  exit 1
fi

from husky.

Git hooks are now all run via sh -e behind the scene. Shebang and set -e can be removed. For compatibility with WIndows user, it's recommended to use POSIX syntax. Otherwise, WIndows users won't be able to contribute (or at least will have to skip git hooks).

from husky.

Sure that works, but be aware that this will have global performance impacts as dash is a lot faster than bash.

It's most certainly going to be negligible for your git hooks, but might not be for system boot times and other applications.

Please read the first link I sent. Here's another direct source from the Ubuntu Wiki. The first paragraph explains crucial things that ChatGPT did not warn you about, at least not in the text you pasted here.

from husky.

Husky thing.

Is there no workaround for windows users to specify a shell that works for them? I'm flustered that the shebang lines in my scripts are ignored. It seems like I should be able to specify the shell in which my commands are run.

to be clear: I want the same scripts to work in macos/ubuntu/ubuntu-wsl

Edit. again: I love the idea behind husky -- but this is not intuitive and cost several hours of development time today. I'd love to contribute what I can to address the issue, but I feel like there's a philosophic issue here that I need to understand before proceeding. I'd settle for an update to the docs saying that husky expects scripts to be written in a 100% POSIX compliant shell, that would have saved a lot of time, and I'll be happy to PR that update for you. However, I'd like the choice of shell to be left to the developers, ideally.

from husky.

Hi,

Sorry about that. I've updated docs, in particular:
https://typicode.github.io/husky/how-to.html#bash

from husky.

@tsears I don't know the inner details, but Git on Windows ships with what's necessary to run sh on Windows. So if you make a default install, husky will work on Windows. The same goes for a default install of GitHub App.

However, they don't ship bash, that's why husky encourages is POSIX compliant and encourages it. However, it's still possible to use bash or whatever runtime you prefer (Python, Node, ...), just not recommended for an OSS project.

WSL2 is not mandatory.

from husky.

I just ran into this as well. In my case the hook was triggered in a Github action. I figured out that in Github actions the default shell is dash and not bash. When the husky script calls the hook file it invokes it using sh which would run it as a dash script. Manually updating the husky file for testing and switching it to call the hook with bash allowed the hook to run correctly.

I +1 an option to tell husky how to invoke the hook script

from husky.

I just ran into this as well. In my case the hook was triggered in a Github action. I figured out that in Github actions the default shell is dash and not bash. When the husky script calls the hook file it invokes it using sh which would run it as a dash script. Manually updating the husky file for testing and switching it to call the hook with bash allowed the hook to run correctly.

I +1 an option to tell husky how to invoke the hook script

Thank you for reply!😊

This method seems to solve the problem of not being able to recognize the "[[" syntax, but entering the RegExp will still report a syntax error. This error will only occur when running husky, and will report this error if executed directly in the terminal, such as the following code:

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

branchName="feature/1.1.2"
if [[ $branchName =~ ([a-z]+/([0-9]+\.){2}[0-9]+.*$) ]]; then
    echo ${BASH_REMATCH[1]}
    echo "branch ✅"
else
    echo "branch 🛑"
fi

output in terminal:

feature/1.1.2
branch ✅

output in husky:

.husky/pre-commit:6: parse error near `('
husky - pre-commit hook exited with code 1 (error)

I think this is a problem with husky. How can I solve it to support the use of RegExp in "[["?

from husky.

@barthy-koeln Thank you for the idea, the problem is in ubuntu, but I still want to be able to use [[...]] syntax and regular expressions, so I tried to change the default dash to bash, and by asking gpt, I got the solution :

In Ubuntu, the default /bin/sh interpreter is typically set to dash. If you want to change it to bash, you can use the following command:

sudo dpkg-reconfigure dash

Then, you will see a dialog asking whether you want to use dash as the default /bin/sh interpreter. Choose "No" to use bash instead. The system will then reconfigure alternatives for dash, setting bash as the default /bin/sh interpreter.

Keep in mind that this only changes /bin/sh to use bash and does not affect the ability of users to use bash directly. If you want to change the default shell for a user to bash, you can use the following command:

chsh -s /bin/bash

After running this command, you will be prompted to enter your user password, and the system will change your default shell to bash. Note that this affects the default shell for the current user, not the system-wide /bin/sh.

Then it works for me. Thanks all ! 🥰

from husky.

Git hooks are now all run via sh -e behind the scene. Shebang and set -e can be removed. For compatibility with WIndows user, it's recommended to use POSIX syntax. Otherwise, WIndows users won't be able to contribute (or at least will have to skip git hooks).

Is this a git thing or a husky thing?

from husky.

Husky thing.

from husky.

@typicode - That workaround is not a universal solution due to shell escaping issues among other things. Can you elaborate more on:

For compatibility with WIndows user, it's recommended to use POSIX syntax. Otherwise, WIndows users won't be able to contribute

Windows doesn't have /bin let alone /bin/sh? Are you referring to WSL and its various distro options in particular? Given the penetration of this library I can understand some hesitation towards changing its behavior now, but what about an environment variable that skipped the shebang insertion?

from husky.

I recently started migrating my workflow to WSL2 and I was stumped on this issue for 3 hours today. 😥

from husky.

@typicode How do we use other runtime if shebang are now ignored?

from husky.