Uh oh!
There was an error while loading. Please reload this page.
Add accessors to Command. - #77029
Merged
Merged
Conversation
rust-highfive
commented
Sep 21, 2020
Contributor
r? @kennytm (rust_highfive has picked a reviewer for you, use r? to override) |
Mark-Simulacrum
commented
Sep 21, 2020
Member
The impl seems good (r=me on that aspect), but this will need a libs team member to sign off on the unstable API surface area being added. Let's try r? @dtolnay I think the surface area looks good - we'll probably want to iterate on some of the points in future PRs but this seems good enough to me for unstable API. |
dtolnay
approved these changes
Sep 25, 2020
dtolnay
commented
Sep 25, 2020
Member
Thanks, this looks great. @bors r=Mark-Simulacrum |
bors
commented
Sep 25, 2020
Collaborator
📌 Commit 094d67a has been approved by |
This was referenced Sep 25, 2020
This was referenced Sep 26, 2020
jonas-schievink
commented
Sep 26, 2020
Contributor
@bors r- failed in #77245 (comment) |
ehuss
commented
Sep 27, 2020
ContributorAuthor
Fixed the fuchsia code, sorry I thought I had tested that. |
dtolnay
commented
Oct 1, 2020
Member
@bors r+ |
bors
commented
Oct 1, 2020
Collaborator
📌 Commit c297e20 has been approved by |
Dylan-DPC-zz pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Oct 1, 2020
Add accessors to Command. This adds some accessor methods to `Command` to provide a way to access the values set when building the `Command`. An example where this can be useful is to display the command to be executed. This is roughly based on the [`ProcessBuilder`](https://github.com/rust-lang/cargo/blob/13b73cdaf76b2d9182515c9cf26a8f68342d08ef/src/cargo/util/process_builder.rs#L105-L134) in Cargo. Possible concerns about the API: - Values with NULs on Unix will be returned as `"<string-with-nul>"`. I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept in `Command`. - Does not handle `arg0` on Unix. This can be awkward to support in `get_args` and is rarely used. I figure if someone really wants it, it can be added to `CommandExt` as a separate method. - Does not offer a way to detect `env_clear`. I'm uncertain if it would be useful for anyone. - Does not offer a way to get an environment variable by name (`get_env`). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return a `Option<Option<&OsStr>>`?). - `get_envs` could skip "cleared" entries and just return `&OsStr` values instead of `Option<&OsStr>`. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't display `None` entries. I erred on the side of providing extra information, but I suspect many situations will just filter out the `None`s. - Could implement more iterator stuff (like `DoubleEndedIterator`). I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed. cc rust-lang#44434
bors
commented
Oct 2, 2020
Collaborator
bors
commented
Oct 2, 2020
Collaborator
☀️ Test successful - checks-actions, checks-azure |
11 tasks
6 tasks
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds some accessor methods to
Commandto provide a way to access the values set when building theCommand. An example where this can be useful is to display the command to be executed. This is roughly based on theProcessBuilderin Cargo.Possible concerns about the API:
"<string-with-nul>". I don't think it is practical to avoid this, since otherwise a whole separate copy of all the values would need to be kept inCommand.arg0on Unix. This can be awkward to support inget_argsand is rarely used. I figure if someone really wants it, it can be added toCommandExtas a separate method.env_clear. I'm uncertain if it would be useful for anyone.get_env). I figure this can be added later if anyone really wants it. I think the motivation for this is weak, though. Also, the API could be a little awkward (return aOption<Option<&OsStr>>?).get_envscould skip "cleared" entries and just return&OsStrvalues instead ofOption<&OsStr>. I'm on the fence here. My use case is to display a shell command, and I only intend it to be roughly equivalent to the actual execution, and I probably won't displayNoneentries. I erred on the side of providing extra information, but I suspect many situations will just filter out theNones.DoubleEndedIterator).I have not implemented new std items before, so I'm uncertain if the existing issue should be reused, or if a new tracking issue is needed.
cc #44434