fix: support running sh shim from wsl

[nadalaba]

What:

Support running sh shim from WSL.

Details:

• Previously, the generated sh shim called windows binary progs without .exe which works from msys/cygwin shells but not from wsl. Also, the the target passed to the windows binary prog as a parameter had a unix path on WSL.
• Now, we detect if we are in WSL, and check for the existence of an executable with and without .exe. We also use wslpath to convert parameter's path to a Windows path.

[nadalaba]

hey @owlstronaut can you help with the failing CodeQL CI? Not sure what I can do on my end

[owlstronaut]

Thanks for the PR! I don't know that this will work for us in all cases. As-is, the new basedir_win rewrite kicks in for any Linux host with wslpath on PATH and then unconditionally hands a windows-form path to whatever interpreter runs. That works for your node.exe+shim case you are targeting, but breaks the common WSL cases where the selected interpreter is a POSIX binary.

[nadalaba]

I don't think there's an issue with assuming the interpreter isn't POSIX if we're using cmd-shim. If the interpreter were POSIX, all shims created here would already break when invoked from intended shells (cmd, pwsh, cygwin, msys) since they currently pass Windows-form paths to the interpreter.

On WSL with POSIX interpreters, users shouldn't be using cmd-shim in the first place, the README explicitly recommends symlinks instead.

the new basedir_win rewrite kicks in for any Linux host with wslpath on PATH

I used npm/cli's approach for WSL detection, but I can narrow it down using uname -a and check for *WSL2* instead of *Linux*. Would you prefer that?

[owlstronaut]

Fair point on the posix interpreter concern. But yes, I think it can be narrowed to WSL2 with uname -a. I think also the probe order needs to be flipped to .exe first to match the npm/cli. Could also use a guard on the wslpath for non-zero exits

[nadalaba]

For the wslpath guard, I'm exiting with an error if wslpath fails since a unix fallback path won't work in WSL anyway.

I also added a 4th path check for PROG_EXE (e.g., node.exe) for non-global packages shims (node is not on the same directory as the shim), since WSL doesn't auto append .exe to PATH binaries like other Windows shells do.