-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Command: also print removed env vars #114379
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
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
https://unix.stackexchange.com/a/388849 suggests wrapping a command in a subshell. It's gnarly syntax but it would be copy-pastable.
|
This comment has been minimized.
This comment has been minimized.
I do feel like being able to easily copy-paste the command is a desirable feature. Not worth substantially sacrificing readability for, though. And the subshell syntax, while easily copy-pasteable, is...not exactly appealing. But those seem like the two options here. |
The subshell syntax could be applied conditionally only when an environment variable was unset. For adding variables the prefix approach is sufficient. |
9d22f68
to
8347352
Compare
We already have Or conversely, if we want to worry about subshells, we should also do it for |
@RalfJung Good call. Having it as an executable command seems like the important part; the subshell doesn't seem worth it, and as you said we already alter the surrounding environment. If someone pastes in the command, they can see that it has |
Since this has a noticeable change in user-visible behavior, let's doublecheck consensus: @rfcbot merge |
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members: No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
I don't think this really needs an FCP since the behavior was changed #97176 not too long ago without much fanfare, but ok |
/// After calling [`Command::env_clear`], the iterator from [`Command::get_envs`] will be | ||
/// empty. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While at it I fixed a typo here. At least I am fairly sure this was a typo?
@the8472 do you know if there is an easy way to express "clear the entire environment" in unix commands? I'm thinking maybe I want to represent that as well. It could be something like |
since clearing the environment means that no variable needs to be explicitly unset anymore (since none are set) it can be expressed this way:
|
44b70c5
to
e6120d0
Compare
Ah, that is neat. |
In fact we could use |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
704e268
to
fc75f72
Compare
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon. |
r? libs |
@bors r+ rollup |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#114379 (Command: also print removed env vars) - rust-lang#116034 (add UI test for delimiter errors) - rust-lang#116036 (tests/ui: Split large_moves.rs and move to lint/large_assignments) - rust-lang#116038 (Fall back to _SC_NPROCESSORS_ONLN if sched_getaffinity returns an empty mask) - rust-lang#116039 (Account for nested `impl Trait` in TAIT) - rust-lang#116041 (Add note to `is_known_rigid`) - rust-lang#116049 (give FutureIncompatibilityReason variants more explicit names) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#114379 - RalfJung:command-removed-env-vars, r=m-ou-se Command: also print removed env vars There is no real shell syntax for unsetting an env var so easily, so we have to make one up. But we already do that for showing the 'program' name so I hope that's okay here, too. No strong opinion on what that should look like, I went with `unset(VAR_NAME)` for now.
There is no real shell syntax for unsetting an env var so easily, so we have to make one up. But we already do that for showing the 'program' name so I hope that's okay here, too. No strong opinion on what that should look like, I went with
unset(VAR_NAME)
for now.