-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Shell escape process arguments that are printed out #1673
Conversation
cargo build --verbose does output some command lines that cannot be simply copy and pasted into the shell again. The problem is the arguments which are output exactly like this: --feature="foo" When pasted back into the shell, the shell will parse and remove the double quotes. To counteract this, escape special shell characters when printing commandlines. Cargo will print --feature=\"foo\" instead, which can be pasted back into the shell.
With great help from @retep998
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @huonw (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. 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. |
Successor of #1572. I think Windows support is still WIP. Ok, it was explained that no detection is needed. Just escape " and spaces on windows by quoting the arguments, also replace all backslashes with slashes. Unfortunately the old fail log is gone and I can't find where it failed on windows the last time, but there must be some test that needs to be updated. |
r#""--features=\"default\"""#); | ||
assert_eq!(shell_escape(r#"\path\to\my documents\"#.into()), | ||
r#""/path/to/my documents/""#); | ||
} |
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.
(See above) @retep998 is this the right way to escape? It adds double quotes if it finds double quotes or spaces.
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.
If it has spaces in it then you add double quotes around it. If it has double quotes in it, then you add backslashes. You do not need to add double quotes around it if it has double quotes in it.
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.
ah, ok, I'll fix that.
@bors: try |
⌛ Testing commit f8e0231 with merge 20b67d4... |
💔 Test failed - cargo-win-gnu-32 |
I'd personally recommend not using Also in theory if you're using a MSYS shell on Windows you should use the same escaping as the unix shell, but that can always be implemented later. |
Oh that's a mistake. The intention was for both windows and other to both compile and test always -- which they do on linux. |
pub use self::windows::shell_escape; | ||
|
||
|
||
#[cfg(any(test, target_os = "windows"))] |
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.
er actually I was thinking that this would remove the #[cfg]
attributes in this module entirely, and instead have a top-level function that used if cfg!(...)
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.
I would do this change, it makes sense, but the way I had it now, I tested both versions on any platform.
I'm sorry, I can't really work on something that I can't run & test (i.e. Windows support). |
It would be better to merge this with single platform support only, and then have another contributor pick up the windows support -- in a PR that they can develop & test on that platform. |
The Windows bots are failing because backslashes are being translated to forward slashes, so tests need to be updated, but I'm also not 100% convinced that we can do this kind of translation as it's changing the input. Do you have a link to the documentation for Windows on how the string may be escaped? |
Thanks, I didn't use any docs, I just talked with @retep998 :) |
Shell escape process arguments that are printed out
cargo build --verbose does output some command lines that cannot be
simply copy and pasted into the shell again. The problem is the
arguments which are output exactly like this: --feature="foo"
When pasted back into the shell, the shell will parse and remove the
double quotes. To counteract this, escape special shell characters when
printing commandlines. Cargo will print --feature="foo" instead, which
can be pasted back into the shell.