Pass OsStr/OsString args through to the process spawned by cargo run. #6849
Conversation
To avoid breaking other (external) callers of ops::run(), this adds a new function ops::run_os() taking an &[OsString], and turns ops::run() into a wrapper (keeping its original signature) that calls run_os().
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
rust-highfive
added
the
S-waiting-on-review
|
Thanks for this! I see you've preserved the If you're interested I suspect we need similar treatment to subcommands and commands like that (this probably isn't the only one that needs to migrate to |
|
Ok; I've updated |
|
@bors: r+ Sounds good to me! |
|
📌 Commit 6d066a6 has been approved by |
bors
added
S-waiting-on-bors
… r=alexcrichton Pass OsStr/OsString args through to the process spawned by cargo run. This is intended to fix #2511, allowing non-UTF8 arguments to be passed through from cargo run to the spawned process. I was not sure whether the interface of cargo::ops needs to remain unchanged - I assume it does, so I added cargo::ops::run_os() taking &[OsString], and retained cargo::ops::run() with its current signature. If it's ok to change the internal cargo API then it may be better to just pass &[OsString] to run(). I have not tried to pass through OsStr/OsString to other places that could reasonably use them. Just one test added covering this path. It is restricted to `cfg(unix)` due to use of `std::os::unix::ffi::OsStrExt`. This is my first pull request so I expect there will be changes needed to make this mergeable.
|
☀️ Test successful - checks-travis, status-appveyor |
Update cargo 16 commits in 6f3e9c367abb497c64f360c3839dab5e74928d5c..b6581d383ed596b133e330011658c6f83cf85c2f 2019-04-04 14:11:33 +0000 to 2019-04-16 16:02:11 +0000 - Fix new_warning_with_corrupt_ws missing "USER". (rust-lang/cargo#6857) - Ignore Clippy redundant_closure (rust-lang/cargo#6855) - Pass OsStr/OsString args through to the process spawned by cargo run. (rust-lang/cargo#6849) - Bump to 0.37.0 (rust-lang/cargo#6852) - Fix test include_overrides_gitignore. (rust-lang/cargo#6850) - Clarify optional registry key behaviour (rust-lang/cargo#6851) - Ensure Summary::checksum works for registry crates (rust-lang/cargo#6842) - Better error if PathSource::walk can't access something. (rust-lang/cargo#6841) - Improve warning in `cargo new` with parse error. (rust-lang/cargo#6839) - Improve error message for `publish` key restriction. (rust-lang/cargo#6838) - Remove `Freshness` from `DependencyQueue` (rust-lang/cargo#6832) - testsuite: cleanup for `alternative-registries` (rust-lang/cargo#6837) - Improve error message to rerun a test in a workspace. (rust-lang/cargo#6824) - Fix mutable_borrow_reservation_conflict warning. (rust-lang/cargo#6829) - Add install-upgrade. (rust-lang/cargo#6798) - Clarify docs of install without <crate> (rust-lang/cargo#6823)
This is intended to fix #2511, allowing non-UTF8 arguments to be passed through from cargo run to the spawned process. I was not sure whether the interface of cargo::ops needs to remain unchanged - I assume it does, so I added cargo::ops::run_os() taking &[OsString], and retained cargo::ops::run() with its current signature. If it's ok to change the internal cargo API then it may be better to just pass &[OsString] to run().
I have not tried to pass through OsStr/OsString to other places that could reasonably use them. Just one test added covering this path. It is restricted to
cfg(unix)due to use ofstd::os::unix::ffi::OsStrExt.This is my first pull request so I expect there will be changes needed to make this mergeable.