Shell commands don't work in rolling release on Windows any more (Bash not found)

Description of the bug:

When using any rule that uses a shell action (e.g. genrule), the rolling release now hardcodes c:\tools\msys64\usr\bin\bash.exe as location of Bash, no matter where MSys64 is actually installed. Setting BAZEL_SH doesn’t work any more. In the latest release, Bazel would find the MSys tools with or without BAZEL_SH. Maybe commit eeb2e04e52cfad165a1bde33ce2d83a392f53d00 is related since it touches this code. Note that the default installation directory for MSys64 is C:\MSys64, not C:\Tools\MSys64, so I think even as a fallback/default value the filename would be incorrect.

What’s the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Create an empty WORKSPACE file and the following BUILD file:

genrule(
    name = "foo",
    outs = ["foo.txt"],
    cmd = "echo bar > $@",
)

Then run

SET USE_BAZEL_VERSION=rolling
bazelisk build //:all

No matter whether BAZEL_SH is set or not, Bazel will try to find Bash at c:\tools\msys64\usr\bin\bash.exe, which fails unless it’s actually installed at that location. (The default installation directory is C:\MSYS64, not C:\Tools\MSYS64.)

Which operating system are you running Bazel on?

Microsoft Windows [Version 10.0.17763.2803]

What is the output of bazel info release?

release 6.0.0-pre.20220630.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What’s the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

irrelevant

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

No response

[meteorcloudy]

OK, I’ll look into this today

[fmeum]

@meteorcloudy I think that this should be labeled a release blocker. For example, rules_jvm_external uses genrule to generate its @maven “alias” repo, which means that it currently can’t be used on Windows at all.