-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add accessors to Command. #77029
Add accessors to Command. #77029
Conversation
r? @kennytm (rust_highfive has picked a reviewer for you, use r? to override) |
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. |
Thanks, this looks great. @bors r=Mark-Simulacrum |
📌 Commit 094d67a has been approved by |
@bors r- failed in #77245 (comment) |
094d67a
to
c297e20
Compare
Fixed the fuchsia code, sorry I thought I had tested that. |
@bors r+ |
📌 Commit c297e20 has been approved by |
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
☀️ Test successful - checks-actions, checks-azure |
This adds some accessor methods to
Command
to 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 theProcessBuilder
in 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
.arg0
on Unix. This can be awkward to support inget_args
and is rarely used. I figure if someone really wants it, it can be added toCommandExt
as 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_envs
could skip "cleared" entries and just return&OsStr
values 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 displayNone
entries. I erred on the side of providing extra information, but I suspect many situations will just filter out theNone
s.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