| Age | Commit message (Collapse) | Author | Lines |
|---|
|
An empty line between the "Basic usage:" text and the example is required to
properly format the code. Without the empty line, the example is not formatted
as code.
|
|
Papercut
r? @steveklabnik
|
|
|
|
|
|
Spawning a child process and writing to its stdin is a bit tricky due to
`as_mut` and having to use a limited borrow. An example for this might
help newer users.
|
|
This is much nicer for callers who want to short-circuit real I/O errors
with `?`, because they can write this
if let Some(status) = foo.try_wait()? {
...
} else {
...
}
instead of this
match foo.try_wait() {
Ok(status) => {
...
}
Err(err) if err.kind() == io::ErrorKind::WouldBlock => {
...
}
Err(err) => return Err(err),
}
The original design of `try_wait` was patterned after the `Read` and
`Write` traits, which support both blocking and non-blocking
implementations in a single API. But since `try_wait` is never blocking,
it makes sense to optimize for the non-blocking case.
Tracking issue: https://github.com/rust-lang/rust/issues/38903
|
|
Fix a few impl stability attributes
The versions show up in rustdoc.
|
|
Expand documentation of process::exit and exec
Show a conventional way to use process::exit when destructors are considered important and also
mention that the same caveats wrt destructors apply to exec as well.
|
|
The versions show up in rustdoc.
|
|
Add std::process::Command::envs()
`Command::envs()` adds a vector of key-value pairs to the child
process environment all at once. Suggested in #38526.
This is not fully baked and frankly I'm not sure it even _works_, but I need some help finishing it up, and this is the simplest way to show you what I've got. The problems I know exist and don't know how to solve, from most to least important, are:
* [ ] I don't know if the type signature of the new function is correct.
* [x] The new test might not be getting run. I didn't see it go by in the output of `x.py test src/libstd --stage 1`.
* [x] The tidy check says ``process.rs:402: different `since` than before`` which I don't know what it means.
r? @brson
|
|
* Command::envs() now takes anything that is IntoIterator<Item=(K, V)>
where both K and V are AsRef<OsStr>.
* Since we're not 100% sure that's the right signature, envs() is
now marked unstable. (You can use envs() with HashMap<str, str> but
not Vec<(str, str)>, for instance.)
* Update the test to match.
* By analogy, args() now takes any IntoIterator<Item=S>, S: AsRef<OsStr>.
This should be uncontroversial.
|
|
Show a conventional way to use process::exit when destructors are considered important and also
mention that the same caveats wrt destructors apply to exec as well.
|
|
* give the new feature its own feature tag
* correct a lifetime problem in the test
* use .output() instead of .spawn() in the test so that output is
actually collected
* correct the same error in the test whose skeleton I cribbed
|
|
std: Add a nonblocking `Child::try_wait` method
This commit adds a new method to the `Child` type in the `std::process` module
called `try_wait`. This method is the same as `wait` except that it will not
block the calling thread and instead only attempt to collect the exit status. On
Unix this means that we call `waitpid` with the `WNOHANG` flag and on Windows it
just means that we pass a 0 timeout to `WaitForSingleObject`.
Currently it's possible to build this method out of tree, but it's unfortunately
tricky to do so. Specifically on Unix you essentially lose ownership of the pid
for the process once a call to `waitpid` has succeeded. Although `Child` tracks
this state internally to be resilient to multiple calls to `wait` or a `kill`
after a successful wait, if the child is waited on externally then the state
inside of `Child` is not updated. This means that external implementations of
this method must be extra careful to essentially not use a `Child`'s methods
after a call to `waitpid` has succeeded (even in a nonblocking fashion).
By adding this functionality to the standard library it should help canonicalize
these external implementations and ensure they can continue to robustly reuse
the `Child` type from the standard library without worrying about pid ownership.
|
|
This commit adds a new method to the `Child` type in the `std::process` module
called `try_wait`. This method is the same as `wait` except that it will not
block the calling thread and instead only attempt to collect the exit status. On
Unix this means that we call `waitpid` with the `WNOHANG` flag and on Windows it
just means that we pass a 0 timeout to `WaitForSingleObject`.
Currently it's possible to build this method out of tree, but it's unfortunately
tricky to do so. Specifically on Unix you essentially lose ownership of the pid
for the process once a call to `waitpid` has succeeded. Although `Child` tracks
this state internally to be resilient to multiple calls to `wait` or a `kill`
after a successful wait, if the child is waited on externally then the state
inside of `Child` is not updated. This means that external implementations of
this method must be extra careful to essentially not use a `Child`'s methods
after a call to `waitpid` has succeeded (even in a nonblocking fashion).
By adding this functionality to the standard library it should help canonicalize
these external implementations and ensure they can continue to robustly reuse
the `Child` type from the standard library without worrying about pid ownership.
|
|
Command::envs() adds a vector of key-value pairs to the child
process environment all at once. Suggested in #38526.
|
|
|
|
|
|
|
|
Implement `fmt::Debug` for all structures in libstd.
Part of https://github.com/rust-lang/rust/issues/31869.
Also turn on the `missing_debug_implementations` lint at the crate
level.
|
|
Part of https://github.com/rust-lang/rust/issues/31869.
Also turn on the `missing_debug_implementations` lint at the crate
level.
|
|
Fixes https://github.com/rust-lang/rust/issues/35046.
|
|
Add examples for exit function
r? @frewsxcv
|
|
Add std::os::windows::process::CommandExt. Fixes #37827
This adds a CommandExt trait for Windows along with an implementation of it
for std::process::Command with methods to set the process creation flags that
are passed to CreateProcess.
|
|
|
|
Document that Process::command will search the PATH
|
|
|
|
|
|
add_creation_flags methods. Fixes #37827
This adds a CommandExt trait for Windows along with an implementation of it
for std::process::Command with methods to set the process creation flags that
are passed to CreateProcess.
|
|
This calls libc abort on Unix and fastfail on Windows.
|
|
Working asmjs and wasm targets
This patch set results in a working standard library for the asmjs-unknown-emscripten and wasm32-unknown-emscripten targets. It is based on the work of @badboy and @rschulman.
It does a few things:
- Updates LLVM with the emscripten [fastcomp](https://github.com/rust-lang/llvm/pull/50) patches, which include the pnacl IR legalizer and the asm.js backend. This patch is thought not to have any significant effect on existing targets.
- Teaches rustbuild to correctly link C code with emscripten
- Updates gcc-rs to work correctly with emscripten
- Teaches rustbuild to run crate tests for emscripten with node
- Modifies Thread::new to return an error on emscripten, to facilitate debugging a common failure mode
- Modifies libtest to run in single-threaded mode for emscripten
- Ignores a host of tests that don't work yet, mostly dealing with threads and I/O
- Updates libc with wasm32 definitions (presently the same as asmjs)
- Adds a wasm32-unknown-emscripten target that feeds the output of LLVM's asmjs backend through emcc to generate wasm
Notes and caveats:
- This is only known to work with `--enable-rustbuild`.
- The wasm32 target can't be tested correctly yet because of issues in compiletest and limitations in node https://github.com/kripken/emscripten/issues/4542, but hello.rs does seem to work when run on node via the binaryen interpreter
- This requires an up to date installation of the emscripten sdk from its incoming branch
- Unwinding is very broken
- When enabling the emscripten targets jemalloc is disabled for all targets, which results in test failures for the host
Next steps are to fix the jemalloc issue, start building the two emscripten targets on the auto builders, then start producing nightlies.
https://github.com/rust-lang/rust/issues/36317 tracks work on this.
Fixes https://github.com/rust-lang/rust/issues/36515
Fixes https://github.com/rust-lang/rust/issues/36515
Fixes https://github.com/rust-lang/rust/issues/36356
|
|
|
|
|
|
|
|
|
|
|
|
* Link to `process::Command` from `process::Child`.
* Move out inline Markdown link in doc comment.
* Link to `process::Child::wait` from `process::Child`.
* Link to `process::Child` from `process::ChildStdin`.
* Link to `process::Child` from `process::ChildStdout`.
* Link to `process::Child` from `process::ChildStderr`.
|
|
|
|
Also, do not repeat name of type
|
|
|
|
std: Allow creating ExitStatus from raw values
Sometimes a process may be waited on externally from the standard library, in
which case it can be useful to create a raw `ExitStatus` structure to return.
This commit extends the existing Unix `ExitStatusExt` extension trait and adds a
new Windows-specific `ExitStatusExt` extension trait to do this. The methods are
currently called `ExitStatus::from_raw`.
cc #32713
|
|
|
|
Sometimes a process may be waited on externally from the standard library, in
which case it can be useful to create a raw `ExitStatus` structure to return.
This commit extends the existing Unix `ExitStatusExt` extension trait and adds a
new Windows-specific `ExitStatusExt` extension trait to do this. The methods are
currently called `ExitStatus::from_raw`.
cc #32713
|
|
Extends rustdoc on how to caputure output
- The documentation is quite about how to caputure a process' output when using
` std::process::Child::wait_with_output()`.
- This PR adds an example for this particular use case.
|
|
std: Fix inheriting stdin on status()
This regression was accidentally introduced in #31618, and it's just flipping a
boolean!
Closes #32254
|
|
Automated conversion using the untry tool [1] and the following command:
```
$ find -name '*.rs' -type f | xargs untry
```
at the root of the Rust repo.
[1]: https://github.com/japaric/untry
|
|
Since I changed no_run to should_panic on some tests, the were run but
two lacked an actual assertion. Further, I missed to check the return
type on another test.
|
|
- All Rust Doc tests execute the same command `/bin/cat file.txt` which
`should_panic` on all platforms consistently, because either
`/bin/cat` or `file.txt` do not exist.
|
|
|
|
- After discussing with @alexcrichton, the initial commit has been fine.
This reverts commit 3b5cfa3ecf4e44b251ce121ab5dcf53c35de8eea.
|
