Skip to content
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

Merged
merged 1 commit into from
Oct 2, 2020
Merged

Add accessors to Command. #77029

merged 1 commit into from
Oct 2, 2020

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Sep 21, 2020

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 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 Nones.
  • 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 #44434

@rust-highfive
Copy link
Collaborator

r? @kennytm

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 21, 2020
@Mark-Simulacrum
Copy link
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.

@rust-highfive rust-highfive assigned dtolnay and unassigned kennytm Sep 21, 2020
@dtolnay
Copy link
Member

dtolnay commented Sep 25, 2020

Thanks, this looks great.

@bors r=Mark-Simulacrum

@bors
Copy link
Contributor

bors commented Sep 25, 2020

📌 Commit 094d67a has been approved by Mark-Simulacrum

@bors bors added S-waiting-on-bors 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 Sep 25, 2020
@jonas-schievink
Copy link
Contributor

@bors r- failed in #77245 (comment)

@bors bors added S-waiting-on-author 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 Sep 26, 2020
@ehuss
Copy link
Contributor Author

ehuss commented Sep 27, 2020

Fixed the fuchsia code, sorry I thought I had tested that.

@dtolnay
Copy link
Member

dtolnay commented Oct 1, 2020

@bors r+

@bors
Copy link
Contributor

bors commented Oct 1, 2020

📌 Commit c297e20 has been approved by dtolnay

@bors bors added S-waiting-on-bors 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 Oct 1, 2020
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
Copy link
Contributor

bors commented Oct 2, 2020

⌛ Testing commit c297e20 with merge 154f1f5...

@bors
Copy link
Contributor

bors commented Oct 2, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: dtolnay
Pushing 154f1f5 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 2, 2020
@bors bors merged commit 154f1f5 into rust-lang:master Oct 2, 2020
@rustbot rustbot added this to the 1.48.0 milestone Oct 2, 2020
@bors bors mentioned this pull request Oct 2, 2020
11 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants