-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
std::process::Command sometimes ignores PATH env variable on Windows #122660
Comments
Ooph yeah, this is semi-intentional but for historic reasons. So please bare with me while I give a history lesson 🙂 The search order in At some point some code was added to try to mimic Linux's search order but it was super buggy, Maybe it worked originally but broke over time due to later refactoring that went untested. This lead to (amongst other things) the behaviour you've seen. When I came along, it was to fix a security issue. We didn't want to ever search the current directory so I rewrote the search manually. I opted to (mostly) preserve the existing behaviour except for removing the current directory because I wanted to avoid too many technically breaking changes at once. I did admittedly fix some bugs though. The issue now is deciding which behaviour we want to use consistently. This may involve breaking someone's workflow. Our options are:
Additionally there's the question of what to do about the system paths that In any case this is ultimately an API question so tagging appropriately. |
In case the above wasn't entirely clear I'll try to explictly list the current state and future options. Current state:
Option 1:
Option 2:
Option 3:
Option 4:
Option 5:
Option 6:
Option 7:
|
By default, the system path Searching Regarding the options, it would be convenient (for me, as Rust developer) if the This seems like a situation where we will definitely break someone's workflow, no matter what approach we choose. |
Okay I kinda fell down a rabbithole with this, apologies in advance. I think Windows should probably follow the Unix-ish variant of using the child's PATH (if set by However:
I think PATH-only is a reasonable default that is relatively easy to get consistent across platforms, especially since Rust provides ways to query both the executable directory, and the working directory, so the behaviour can be implemented by the user, should they need it (Although adding them to PATH manually is maybe a little clunky.) In a perfect world, what I would want is:
Needless to say, all of this is a pretty big mess. I'm advocating for following the principle of least surprise here as much as possible. Notably, it makes "check the value of PATH" be the correct first troubleshooting step on all platforms. |
On GitHub actions ubuntu runners we had |
I'm building a tool which spawns a shell process. Here's a very simplified version:
On my Windows system, there are 2 bash versions:
C:\Windows\System32\bash.exe
C:\Program Files\Git\bin\bash.exe
The
PATH
environment variable is configured asPATH=C:\Program Files\Git\bin\;C:\Windows\System32\;...
, so the MinGW version should have precedence. And when I run the following fromcmd.exe
:it produces, the expected output:
Yet, the Rust example will ignore the
PATH
, use the WSL instead and output:The funny thing is that if I modify the example and just add some random environment variable:
then the Rust example will use the expected MinGW version and produce:
I have investigated a little bit and I think the problem lies in windows search path implementation
When
std::process::Command::env
is set, the1. Child paths
branch searches thePATH
as first and it works as expected.Otherwise, the
3 & 4. System paths
part of code finds thebash
executable underC:\Windows\System32
which produces the unexpected behavior.I think we could fix this by searching
5. Parent paths
before3 & 4. System paths
but I'm not sure if this change could negatively impact something else.Tested on
The text was updated successfully, but these errors were encountered: