You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello! Thanks for the great library, I'm finding it very useful in my current project however I think I've recently run into a bug when spawning an async command converted from a std::process::Command. This should be a simplified reproducible test case highlighting the problem:
When running the above, you should see that hello world is printed to the console, even though we've explicitly said that Stdout should be redirected to Stdio::null().
As far as I can see, this is due to:
the implementation of spawn() defaults the value of stdin to Stdio::inherit():
the implementation of from() marks stdin as not having been explicitly set (ie. stdin: false), even though it might have been explicitly set on the inner command:
The work-around is to set .stdin()/.stdout()/.stderr()after converting from a sync command to an async command, but obviously this is a bit of a gotcha and isn't immediately obvious that it's necessary.
Ideally the solution would be to set stdout: true in the implementation of From<std::process::Command> when it's already been explicitly set for inner, I'm not sure if there is a way to know whether that's the case? Alternatively, maybe this behaviour just needs to be explicitly documented?
Or perhaps: why do we even need to handle the defaulting in this library? Isn't that going to be handled by std::process::Command anyways? The documentation does state that "By default, stdin, stdout and stderr are inherited from the parent.", so perhaps there isn't any reason to do so in this library?
I'm happy to implement any changes / fixes (including just docs improvements), but would just need guidance as per the above on what you think the right solution might be. Thanks!
The text was updated successfully, but these errors were encountered:
Ideally the solution would be to set stdout: true in the implementation of From<std::process::Command> when it's already been explicitly set for inner, I'm not sure if there is a way to know whether that's the case? Alternatively, maybe this behaviour just needs to be explicitly documented?
If there is a way to detect if the values were set in the builder, I'm not aware of it. I need to do some reading, but from a quick glance the Stdio values are set for a reason, so I think adding docs would be the right call.
Hello! Thanks for the great library, I'm finding it very useful in my current project however I think I've recently run into a bug when spawning an async command converted from a
std::process::Command
. This should be a simplified reproducible test case highlighting the problem:When running the above, you should see that
hello world
is printed to the console, even though we've explicitly said that Stdout should be redirected toStdio::null()
.As far as I can see, this is due to:
spawn()
defaults the value ofstdin
toStdio::inherit()
:async-process/src/lib.rs
Lines 971 to 983 in e84c3fd
from()
marksstdin
as not having been explicitly set (ie.stdin: false
), even though it might have been explicitly set on the inner command:async-process/src/lib.rs
Lines 1040 to 1051 in e84c3fd
The work-around is to set
.stdin()
/.stdout()
/.stderr()
after converting from a sync command to an async command, but obviously this is a bit of a gotcha and isn't immediately obvious that it's necessary.Ideally the solution would be to set
stdout: true
in the implementation ofFrom<std::process::Command>
when it's already been explicitly set forinner
, I'm not sure if there is a way to know whether that's the case? Alternatively, maybe this behaviour just needs to be explicitly documented?Or perhaps: why do we even need to handle the defaulting in this library? Isn't that going to be handled by
std::process::Command
anyways? The documentation does state that "By default, stdin, stdout and stderr are inherited from the parent.", so perhaps there isn't any reason to do so in this library?I'm happy to implement any changes / fixes (including just docs improvements), but would just need guidance as per the above on what you think the right solution might be. Thanks!
The text was updated successfully, but these errors were encountered: