`just` prioritizes System32 over `$Path`; is impossible to put `bash` on `$Path` if you have WSL2 installed

[cspotcode]

This is a doozy, but I've done my best to explain it concisely.

Bug

just on Windows, by virtue of std::process::Command, does not respect $Path they way we want when resolving shell or interpreter executables. This means, when you try to use bash and you have a bash.exe on your $Path (perhaps it's Git Bash), and you coincidentally have WSL2 installed, just ignores your preferred bash.exe and instead calls C:\Windows\System32\bash.exe, which launches a shell inside the WSL2 guest virtual machine, not a bash shell on your host.

This breaks integration tests on Windows, because test.rs sets --shell bash.

It's also a bug for anyone who wants to use Git Bash or any other bash.exe as their just shell.

Fix

My proposed fix is for just to resolve executables to absolute paths using "which" or "pathsearch" crates. It can use this implementation consistently across:

• which() function
• set shell
• [script()] / set script-interpreter

We already want which() functionality, so using it to resolve shells and interpreters to absolute paths, fixing a bug in the process, and fixing the integration tests on Windows: seems like a win all around.

Reproduction

You can reproduce it quickly if you have WSL2 installed:

# Put C:\Program Files\git\bin at the top of $Path
# Open any shell to confirm this works:
$ bash -c 'if wslinfo --version >/dev/null 2>&1; then echo BAD we are in WSL2 ; else echo GOOD, we are in Git Bash! ; fi'
GOOD, we are in Git Bash!

Now create this justfile:

set shell := ["bash", "-c"]
@default:
    if wslinfo --version >/dev/null 2>&1; then echo BAD we are in WSL2 ; else echo GOOD, we are in Git Bash! ; fi

...and run it in the shell:

$ just
BAD we are in WSL2

I've created a more exhaustive reproduction here: https://github.com/cspotcode/repros2/tree/just-path-behavior-windows

Q&A

Why in the world does std::process::Command prioritize System32?

EDIT previous link was outdated

These rust release notes explain it clearly.

It checks in this order: child's $PATH if it's been explicitly set, then System32, then parent's $PATH
We want it to check $PATH before System32. (note that $PATH always contains a System32 entry, too)

It makes some (buggy, undocumented) attempts to resolve the executable only when a PATH env var has been explicitly set. In just's case, it doesn't resolve the executable, leaving it to CreateProcess which checks a bunch of places before $Path: the local directory, System32/, etc.

https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessa

But isn't default resolution the correct (albeit strange) behavior, since it's the rust standard library?

I argue: no, it's not what we want. The proof is that other shells intentionally don't behave this way! They resolve the target executable according to $Path before the System32 fallback, which matches user expectations. They do not give C:\Windows\System32 special treatment.

What's the problem with using WSL2 bash.exe as your shell?

It might work sometimes, break in others. For example, the C: drive is often mounted at a different location in WSL. Ultimately, just should respect $Path the same way that other shells do both on Windows and Linux.

Related tickets

#2926
#2826
rust-lang/rust#15149
rust-lang/rust#37519

[nooscraft]

@cspotcode @casey plz look at my PR when you get a chance. thanks

[cspotcode]

I realized that rust's std::process::Command behavior is slightly different than what I linked above -- it has since been updated -- but it still prioritizes System32 over $PATH. When I have time I'll update the ticket description with an up-to-date link. Importantly, my reproduction still proves that the issue exists.

We could do one of two things to fix:
a) explicitly set $Path on every Command, always. This trigger's std::process::Command's resolution behavior to check $Path before System32, not after
b) explicitly resolve to an absolute path using an in-process which() implementation

a) is easier, but which() still needs to be fixed to address #2926.

[cspotcode]

A workaround is to explicitly export PATH :=. This causes just to set it on std::process::Command, triggering PATH lookup before System32 as opposed to after.

export PATH := env('PATH')

[nooscraft]

Let me take another look at this, then. I may not have fully understood the workaround initially.

[nooscraft]

@cspotcode
You're right that explicitly setting PATH via export PATH := env('PATH') can help in some cases by ensuring PATH is set on the Command object.

I ended up taking a slightly different approach in the PR. Instead of relying on Rust's Command potentially doing PATH resolution when PATH is explicitly set, it explicitly resolve executables to absolute paths before creating the Command. So rather than:

Command::new("bash") 
  .env("PATH", path_value)

We do:

let resolved = which::resolve_executable("bash", working_directory)?;
Command::new(resolved)  // "C:\Program Files\Git\bin\bash.exe"

This gives us a few benefits:

• Full control over PATH resolution order (respects PATH order, not System32 priority)
• Proper PATHEXT handling on Windows (.exe, .bat, .cmd, etc.)
• Better error messages when executables aren't found
• Works consistently for shell, script-interpreter, and shebang resolution

I’m not claiming that the way I’ve done it is the absolute best, but I’m genuinely curious, have you seen the workaround work reliably in practice? I’m always open to feedback if there’s a simpler or more robust approach we should consider.

[casey]

Thanks for opening this issue, and sorry for neglecting it!

The fix in #2966 seems reasonable, especially since it's so simple.

@cspotcode Could you provide links to shells which search PATH first? If popular shells do this, it gives me more confidence that #2966 is the right fix.

[cspotcode]

Both powershell and bash / sh / ash / dash (Git for Windows or the busybox you can get from winget) search PATH. The first code block of my reproduction can be used to test this. It can be executed from any shell. Despite invoking bash, it is not testing bash's behavior. Rather, it is testing the current shell's behavior (be it powershell, or any other shell) to test how it resolves bash.exe: from System32 first or from PATH first.

[casey]

Fixed in #3160. This adds a new method CommandExt::resolve, which respects both PATH and PATHEXT on Windows, and uses it wherever commands are launched.

[casey]

By the way, if anyone wants to test this on master it would be much appreciated!