Tracking Issue for an improved `std::process::Command`

Feature gate: TBD (maybe #![feature(command_2027)]? -- depends on what we actually agree on)

This is a tracking issue for a new API for std::process::Command that would fix the pain points with the current implementation and would be enabled in a future edition.

Some changes / feature proposals:

• Add a lifetime so Command could hold borrowed data
  • It would allow the pre_exec closure to be taken by reference rather than cloned and boxed
• Executable path lookup to only consider $PATH in the parent process and ignore any modified PATH in the child's environment variables
  • This matches the native process spawning behaviour of both Unix and Windows
• Fully commit to either being a transient builder which can only be used once (spawn consumes Self) or a reusable object which can hold state that can be retrieved piecewise
  • Right now it's somewhere in-between
  • Maybe using a drop bomb if Command can only be used once?
    • Counter point: if you start constructing it and encounter an error (e.g. can't open an output file), it should be ok to drop Command and the error without panicking
  • Taking self instead of &mut self could reduce intermediate binding in some cases and/or allow a more liberal sprinkling of must_use
• Executing the same Command multiple times in a way that doesn't modify its internal state
• Preserve the ability to debug print Command after the spawned process failed
  • Useful information is often returned when the spawned process fails with non-zero error (so this can't be handled by just reporting an error while the spawn itself completes.
• Only inherit handles that are explicitly allowed (on Windows)
  • By default, only the stdio handle would be inherited and nothing else would
  • We currently attempt to avoid problems with automatic inheritance by synchronising all calls to CreateProcess but that isn't at all robust

Note that some of these proposals are in conflict with each other. This feature is in a brainstorming phase, but we wanted to have one place where we can collect it all and use that to start discussing ACPs, experiments, a future RFC etc.

The initial brainstorming happened here: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/A.20new.20.60std.3A.3Aprocess.3A.3ACommand.60/

Public API

TBD

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• Gather ideas
• Run experiments
• Propose a coherent set forming the Command
• Decide on plan to replacing the existing Command
• Write an RFC
• Implementation: #...
• Final comment period (FCP)^1
• Stabilization PR

Unresolved Questions

• None yet.

Start with the std::process::Command API and the linked Zulip discussion, then review each proposal and its conflicts. The issue names no implementation files or tests; progress means gathering ideas, running experiments, agreeing on a coherent API, and moving toward an RFC as listed in the checklist.