Display environment variables for rustc commands

[ghost]

This picks up on the work done in PR #5683.

The extra output is only displayed with -vv.

The Windows output has the form set FOO=foo && BAR=bar rustc ... instead of
the form that suggested in #5683 to make escaping easier and since it's
simpler.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @ehuss (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.

[Eh2406]

Real question, Does that form work? Opening CMD I get:

>set FOO=foo && BAR=bar rustc
'BAR' is not recognized as an internal or external command,
operable program or batch file.

[ehuss]

@Eh2406 You need set before each variable.

This doesn't work very well on Windows. The escaping rules of cmd are finicky. For example, set FOO='bar' is embedding the single quotes within the variable (cmd doesn't use single quotes for strings). Also, it is space sensitive, so set FOO=one && BAR=two && rustc... will embed spaces after each variable (FOO is one ). I think avoiding the quotes, and just escaping special characters (like ^") might be an option. And avoid the space between commands (not sure if there's a way to avoid that).

Also, would it be possible to detect the shell and use different syntax? I suspect cmd users are rare (at least I don't know any). Most people I've seen use bash or powershell.

[ghost]

@Eh2406

set FOO=foo && BAR=bar rustc

That was a mistake in my description, I acutally implemented set FOO=foo && set BAR=bar && rustc.

@ehuss

Also, it is space sensitive, so set FOO=one && BAR=two && rustc... will embed spaces after each variable (FOO is one ).

This should be fixed now.

I think avoiding the quotes, and just escaping special characters (like ^") might be an option.

So if I understand you, I should not shell escape the variables and only escape the cmd.exe metacharacters with ^. So "Ben & Jerry's" becomes ^"Ben ^& Jerry^'s^". This seemed to work when I tried it but I'm not sure about this. ProcessBuilder already escapes rustc arguments using shell_escape::escape and doesn't do this (although maybe it should). This article linked from the shell_escape docs seems to indicate that both types of escaping are required.

Also, would it be possible to detect the shell and use different syntax? I suspect cmd users are rare (at least I don't know any). Most people I've seen use bash or powershell.

This is out of scope for me. I have a feeling that the powershell escaping story might be even worse than cmd.exe.

[ehuss]

This seemed to work when I tried it but I'm not sure about this.

I am not sure about it, either. However, from my understanding of cmd syntax, it works a bit differently from command-line parsing syntax. It seems to be more reliable to use ^ escaping. I think the argument escaping is probably already correct, since that goes through a different mechanism.

One thing I can't figure out is how to set an empty variable. set FOO= deletes the variable. I don't think cargo has any variables where that would matter, but it doesn't seem quite right.

This is out of scope for me. I have a feeling that the powershell escaping story might be even worse than cmd.exe.

That's fair.

[alexcrichton]

This looks like a great start to me, thanks @mikerite! I agree that we'll probably want powershell syntax eventually, but for now I think it's fine to add this in and iterate from here

@bors: r+

[bors]

📌 Commit e557f66 has been approved by alexcrichton

[bors]

⌛ Testing commit e557f66 with merge 34320d2...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 34320d2 to master...