Windows: CommandExt::async_pipes by ChrisDenton · Pull Request #97149 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation14 Commits1 Checks0 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
Discussed in tokio-rs/tokio#4670 was the need for third party crates to be able to force process::Command::spawn to create pipes as async.
This implements the suggestion for a async_pipes method that gives third party crates that option.
Example:
use std::process::{Command, Stdio};
Command::new("cmd") .async_pipes(true) .stdin(Stdio::piped()) .stdout(Stdio::piped()) .stderr(Stdio::piped()) .spawn() .unwrap();
Hey! It looks like you've submitted a new PR for the library teams!
If this PR contains changes to any rust-lang/rust public library APIs then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api -T-libs to request review from a libs-api team reviewer. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.
Examples of T-libs-api changes:
- Stabilizing library features
- Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
- Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
- Changing public documentation in ways that create new stability guarantees
- Changing observable runtime behavior of library APIs
r? @kennytm
(rust-highfive has picked a reviewer for you, use r? to override)
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. r=me after minor changes.
📌 Commit f1f614cd5ce8364d1fc5da103553a9c262c1d60f has been approved by m-ou-se
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
@bors r-
Oops, forgot to post the tracking issue for this one. I really shouldn't try to do two things at once. 🙂
Status: This is awaiting some action (such as code changes or more information) from the author.
and removed S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
labels
📌 Commit 740a54c has been approved by m-ou-se
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-author
Status: This is awaiting some action (such as code changes or more information) from the author.
labels
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request
…ou-se
Stdio::makes_pipe
Wrappers around std::process::Command may want to be able to override pipe creation. However, std::process::Stdio is opaque so there's no way to tell if Command was told to create new pipes or not.
This is in some ways a more generic (and cross-platform) alternative to rust-lang#97149. However, unlike that feature, this comes with the price of the user needing to actually create their own pipes rather than reusing the std one. So I think it stands (or not) on its own.
Example
#![feature(stdio_makes_pipe)]
use std::process::Stdio;
let io = Stdio::piped();
assert_eq!(io.makes_pipe(), true);bors added a commit to rust-lang-ci/rust that referenced this pull request
Rollup of 8 pull requests
Successful merges:
- rust-lang#93080 (Implement
core::slice::IterMut::as_mut_sliceandimpl<T> AsMut<[T]> for IterMut<'_, T>) - rust-lang#94855 (Panic when advance_slices()'ing too far and update docs.)
- rust-lang#96609 (Add
{Arc, Rc}::downcast_unchecked) - rust-lang#96719 (Fix the generator example for
pin!()) - rust-lang#97149 (Windows:
CommandExt::async_pipes) - rust-lang#97150 (
Stdio::makes_pipe) - rust-lang#97837 (Document Rust's stance on
/proc/self/mem) - rust-lang#98159 (Include ForeignItem when visiting types for WF check)
Failed merges:
r? @ghost
@rustbot modify labels: rollup
Labels
Area: `std::process` and `std::env`
Operating system: Windows
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the library API team, which will review and decide on the PR/issue.