std: clarify Command reuse docs

[npiesco]

Args persist after execution; probe flags carry into later uses. Add note and example showing fresh Command pattern.

[rustbot]

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[workingjubilee]

This documentation seems more muddling than clarifying: The case presented for making a new Command, probe-only flags, relies on the flags remaining unchanged. But it also says the internal state of Command is altered. Which is it?

[workingjubilee]

I saw your PR to servo.

r? @workingjubilee

[workingjubilee]

While this is a library PR, I am responding to it in accord with MCP 893 because the principle, in my opinion, remains the same across the compiler and library: rust-lang/compiler-team#893

In servo/servo#42340 the PR you originally opened, you are being told by a Servo maintainer that there is no bug and that the change fixes nothing. You provide no justification. You cite no actual build failures. Your "clarification", especially including its example code, encourages a behavior that only makes sense if someone uses that very specific pattern. Otherwise, it is uselessly defensive programming that only makes sense if the implementation of Command is faulty, or if they fail to read the lines before and after this "clarification" that state for the "setting" functions, the Command is mutated, and that the spawned process will use the modified state.

As @sagudev observed: If there is an actual bug, we should fix it. However, in the absence of evidence of an actual bug, there is nothing to fix, and further review of this PR is unjustified, as this is a burdensome PR without motivation.

[npiesco]

While this is a library PR, I am responding to it in accord with MCP 893 because the principle, in my opinion, remains the same across the compiler and library: rust-lang/compiler-team#893

In servo/servo#42340 the PR you originally opened, you are being told by a Servo maintainer that there is no bug and that the change fixes nothing. You provide no justification. You cite no actual build failures. Your "clarification", especially including its example code, encourages a behavior that only makes sense if someone uses that very specific pattern. Otherwise, it is uselessly defensive programming that only makes sense if the implementation of Command is faulty, or if they fail to read the lines before and after this "clarification" that state for the "setting" functions, the Command is mutated, and that the spawned process will use the modified state.

As @sagudev observed: If there is an actual bug, we should fix it. However, in the absence of evidence of an actual bug, there is nothing to fix, and further review of this PR is unjustified, as this is a burdensome PR without motivation.

You're right. I reviewed the documentation better and I was wrong in trying to address it here. Closing and handling in servo build script where Windows non-TTY hang actually occurs. Thanks for feedback!