Shell escape process arguments that are printed out

[bluss]

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.

[rust-highfive]

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.

[bluss]

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.

[bluss]

(See above) @retep998 is this the right way to escape? It adds double quotes if it finds double quotes or spaces.

[retep998]

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.

[bluss]

ah, ok, I'll fix that.

[cmr]

@bors: try

[alexcrichton]

@bors: r+ f8e0231

Thanks!

[bors]

⌛️ Testing commit f8e0231 with merge 20b67d4...

[bors]

💔 Test failed - cargo-win-gnu-32

[alexcrichton]

I'd personally recommend not using #[cfg] here and instead using if cfg!(windows) as it'll allow typechecking on all platforms.

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.

[bluss]

Oh that's a mistake. The intention was for both windows and other to both compile and test always -- which they do on linux.

[alexcrichton]

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!(...)

[bluss]

I would do this change, it makes sense, but the way I had it now, I tested both versions on any platform.

[bluss]

I'm sorry, I can't really work on something that I can't run & test (i.e. Windows support).

[bluss]

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.

[alexcrichton]

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?

[retep998]

http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx
https://msdn.microsoft.com/en-us/library/17w5ykft.aspx?f=255&MSPPError=-2147217396
https://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx

[bluss]

Thanks, I didn't use any docs, I just talked with @retep998 :)