Setting System Environment Variables in Windows

[John Jelinek]

I tried to run a provision script that adds my proxy settings like this:

[Environment]::SetEnvironmentVariable("https_proxy", "PROXYSERVER:PROXYPORT","Machine")

But the variables don't seem to stick. Any ideas how to handle this?

[Alvaro Miranda Aguilera]

more info please.

shell, puppet, chet, ansible, docker.. ?

vm ubuntu,windows?

host ubuntu,windows?

sample vagrantfile?

thanks!
alvaro

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Jelinek IV]

shell windows. That's the command I do for inline.

You received this message because you are subscribed to a topic in the Google Groups "Vagrant" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vagrant-up/M2lKTQIlVTs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vagrant-up+...@googlegroups.com.

[Shawn Neal]

Calling this method is equivalent to calling the SetEnvironmentVariable(String, String, EnvironmentVariableTarget) overload with a value of EnvironmentVariableTarget.Process for the target argument. http://msdn.microsoft.com/en-us/library/z46c489x(v=vs.110).aspx

Try using setx instead http://technet.microsoft.com/en-us/library/cc755104.aspx

[Victor Robertson]

For what it's worth, I'm having a similar issue though am still trying to find a good workaround. Here's the context of my problem:

I have a bootstrap script called via the shell provisioner to install Chef. The script, itself, is simple as it just invokes msiexec.exe with the chef msi. As part of the installation, Chef updates the system's Path environment variable.

This updated environment variable is not available to Vagrant as (I believe), environment variables set from a child process do not propagate to their callers. This includes the WinRM session that Vagrant holds (correct terminology?). Thus, future commands invoked by Vagrant will not show the updated environment variables. This is easily demonstrated by the output for these shell inline scripts post-chef install:

config.vm.provision :shell, :inline => %{($env:Path).Replace(';',"`n")}

config.vm.provision :shell, :inline => %{[System.Environment]::GetEnvironmentVariable("Path","Machine").Replace(';',"`n")}

Output:

==> default: Running provisioner: shell...

    default: Running: inline PowerShell script

==> default: C:\Windows\system32

==> default: C:\Windows

==> default: C:\Windows\System32\Wbem

==> default: C:\Windows\System32\WindowsPowerShell\v1.0\

==> default: Running provisioner: shell...

    default: Running: inline PowerShell script

==> default: C:\Windows\system32

==> default: C:\Windows

==> default: C:\Windows\System32\Wbem

==> default: C:\Windows\System32\WindowsPowerShell\v1.0\

==> default: c:\opscode\chef\bin

==> default: c:\opscode\chef\embedded\bin

Based on some available documentation on MSDN, I don't think it's possible to change the Path of the calling process. The workaround I'm looking for, then, would probably involve either forcing a reconnect to the VM or running inline shell scripts in a truly inlined manner, unlike the current method of creating a temporary script for later invocation.

Might anyone else have ideas to solve this use case outside of running Vagrant twice? If there's no clean workaround, I'm going to propose there be a Vagrant method to reconnect to the VM on GitHub. I'm currently experimenting with workarounds involving killing the connection from the guest, but I'm not sure Vagrant has automatic reconnect functionality.

[Shawn Neal]

You can get around the Chef install/use it in the same Vagrant run by specifying the full path to the chef binary.

chef.binary_path = 'c:/opscode/chef/bin'

[Victor Robertson]

Thanks! That is a much nicer workaround than what I was thinking of.

It's too bad that it's not a general workaround. For that reason, I think I'm still going to put up a feature request on GitHub to see if it gains traction.