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

do not export the MSBuild env-var to the outer shell #2754

Merged
merged 2 commits into from Sep 17, 2017

Conversation

Projects
None yet
3 participants
@0x53A
Contributor

0x53A commented Sep 10, 2017

fixes #2751

/cc @vbfox, sorry about that.

Please review by someone who knows more about batch than me.

@vbfox

This comment has been minimized.

Show comment
Hide comment
@vbfox

vbfox Sep 11, 2017

Contributor

Nice.

Windows version looks 👍 to me, you don't need endlocal btw the end of the script does the same.

About the bash version, bash support setting env variables for only one command:

VAR=value cmd args

Contributor

vbfox commented Sep 11, 2017

Nice.

Windows version looks 👍 to me, you don't need endlocal btw the end of the script does the same.

About the bash version, bash support setting env variables for only one command:

VAR=value cmd args

@0x53A

This comment has been minimized.

Show comment
Hide comment
@0x53A

0x53A Sep 11, 2017

Contributor

you don't need endlocal btw the end of the script does the same.

but it doesn't hurt, right?

bash support setting env variables for only one command:

done. but this is only in the windows branch of the bash script, so I doubt anyone even triggers this codepath.

(the bundled msbuild crashes hard on linux, so the mono msbuild is still used)

Thanks!

Contributor

0x53A commented Sep 11, 2017

you don't need endlocal btw the end of the script does the same.

but it doesn't hurt, right?

bash support setting env variables for only one command:

done. but this is only in the windows branch of the bash script, so I doubt anyone even triggers this codepath.

(the bundled msbuild crashes hard on linux, so the mono msbuild is still used)

Thanks!

@vbfox

This comment has been minimized.

Show comment
Hide comment
@vbfox

vbfox Sep 11, 2017

Contributor

but it doesn't hurt, right?

No, it just restore the env explicitly instead of implicitly.

Contributor

vbfox commented Sep 11, 2017

but it doesn't hurt, right?

No, it just restore the env explicitly instead of implicitly.

@matthid

This comment has been minimized.

Show comment
Hide comment
@matthid

matthid Sep 11, 2017

Member

0x53A the windows code path is for me ;)
I'm using git bash ever since as I don't like cmd or powershell ;)

Member

matthid commented Sep 11, 2017

0x53A the windows code path is for me ;)
I'm using git bash ever since as I don't like cmd or powershell ;)

@0x53A

This comment has been minimized.

Show comment
Hide comment
@0x53A

0x53A Sep 11, 2017

Contributor

I don't like cmd or powershell ;)

I can't understand that at all.

Contributor

0x53A commented Sep 11, 2017

I don't like cmd or powershell ;)

I can't understand that at all.

@0x53A

This comment has been minimized.

Show comment
Hide comment
@0x53A

0x53A Sep 17, 2017

Contributor

@matthid I think this is ready, unless you or @vbfox have any additional feedback.

Contributor

0x53A commented Sep 17, 2017

@matthid I think this is ready, unless you or @vbfox have any additional feedback.

@matthid matthid merged commit dd523ee into fsprojects:master Sep 17, 2017

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details

@0x53A 0x53A deleted the 0x53A:do-not-export-variables branch Sep 17, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment