Rollup merge of #137673 - ChrisDenton:search-path-bug, r=dtolnay

Fix Windows `Command` search path bug

Currently `Command::new` on Windows works differently depending on whether any environment variable is set. For example,

```rust
// Searches for "myapp" in the application and system paths first (aka Windows native behaviour).
Command::new("myapp").spawn();

// Search for "myapp" in `PATH` first
Command::new("myapp").env("a", "b").spawn();
```

This is a bug because the search path should only change if `PATH` is changed for the child (i.e. `.env("PATH", "...")`).

This was discussed in a libs-api meeting where the exact semantics of `Command::new` was not decided but there seemed to be broad agreement that this particular thing is just a bug that can be fixed.

r? libs-api

1 files changed, 2 insertions, 1 deletions

diff --git a/library/std/src/sys/pal/windows/process.rs b/library/std/src/sys/pal/windows/process.rs
index a41dfbfe601..6eff471f386 100644
--- a/library/std/src/sys/pal/windows/process.rs
+++ b/library/std/src/sys/pal/windows/process.rs
@@ -260,9 +260,10 @@ impl Command {
         needs_stdin: bool,
         proc_thread_attribute_list: Option<&ProcThreadAttributeList<'_>>,
     ) -> io::Result<(Process, StdioPipes)> {
+        let env_saw_path = self.env.have_changed_path();
         let maybe_env = self.env.capture_if_changed();
 
-        let child_paths = if let Some(env) = maybe_env.as_ref() {
+        let child_paths = if env_saw_path && let Some(env) = maybe_env.as_ref() {
             env.get(&EnvKey::new("PATH")).map(|s| s.as_os_str())
         } else {
             None