husky: WSL2 (or Linux?) cannot use regular expressions in "[[ ]]" syntax

Terminal used

linux zsh

OS

Ubuntu 22.04.3 in wsl2

➜ uname -a
Linux GOD-BOOK 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5 21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

➜ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.3 LTS
Release:        22.04
Codename:       jammy

Problem

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

merge='Merge'
commitMsg="Merge xxx"
if [[ "$commitMsg" == "$merge"* ]]; then
  echo "OK"
  exit 2
else
  exit 1
fi
  1. run git commit -m 'chore: cache'

then throw an exception

.husky/pre-commit: 6: [[: not found
husky - pre-commit hook exited with code 1 (error)
  1. After checking the information, modify the first line to #!/usr/bin/env bash,but it still didn’t work and the error was the same.

Windows git bash and macos sh work fine.

So

Is this the official reason? How can I solve this problem? Can a certain configuration be modified to support the [[ syntax?

Thanks!

About this issue

  • Original URL
  • State: open
  • Created 6 months ago
  • Comments: 15 (3 by maintainers)

Most upvoted comments

@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.

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

@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.

Hi,

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

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.

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.

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).