Restart Boxstarter without reboot?

Feb 20, 2014 at 9:17 PM
Edited Feb 20, 2014 at 9:40 PM
Is there a way to break out of a Boxstarter installation and restart other than forcing a reboot?

The reason I ask is this. I have a Boxstarter script that installs a bunch of stuff. If the user doesn't already have %ChocolateyBinRoot% set, then I set it at the top of the script to C:\tools. Unfortunately, picking up the change requires exiting Powershell and launching a new instance of Powershell.

So this means that despite changing the variable, if the script does something like cinst sysinternals, it ignores the new %ChocolateyBinRoot% and goes to C:\sysinternals. However, if the user then uninstalls it and runs the same script again, it goes to the right path, because the new Powershell session picks up the path that was specified on the previous run.

Thus, I'm looking for a way to say, "If I just set the %ChocolateyBinRoot%, let's start over with a new Powershell session." I could do that by forcing a reboot after setting it, but I'm hoping to avoid that.

Is there a way to accomplish what I want?
Coordinator
Feb 20, 2014 at 10:11 PM
How do you set the variable? My guess is that you are using the chocolatey command that sets persistent environment variables. In addition to that, I would also do:
$env:ChocolateyBinRoot="c:\tools"
This should make that variable apply to the current session.

Would that work for you?
Feb 20, 2014 at 10:16 PM
I'm doing it the way the Chocolatey Get-BinRoot script does it, which is:

Environment::SetEnvironmentVariable()

You might be right - maybe if I set $env:ChocolateyBinRoot directly it will pick it up in the same session. Let me test that and get back to you.
Feb 21, 2014 at 12:39 AM
Unfortunately, that didn't work. However, in the course of testing this, I discovered that Chocolatey's Get-BinRoot.ps1 also has a bug. It's actually supposed to default to C:\tools, which would be awesome. But it doesn't work, and defaults to the drive root instead. That's why sysinternals installs to C:\sysinternals:

PS C:\chocolatey\chocolateyinstall\helpers\functions> . .\Get-BinRoot.ps1
PS C:\chocolatey\chocolateyinstall\helpers\functions> Get-BinRoot
C:\

Doh! Instead of messing with environment variables in my script, I'm going to go open an issue against Chocolatey. If it works like it's supposed to, then I don't have to do anything. :)
Editor
Feb 21, 2014 at 6:58 AM
Hello bilong,

Thanks for filing the issue, and raising the Pull Request, it really is much appreciated!

Gary
Feb 21, 2014 at 4:39 PM
Glad I could help! I figured a one-line code change was perfect for my first ever contribution to a GitHub project. :-)

In the meantime I seem to have found a workaround. This approach works:
if ([Environment]::GetEnvironmentVariable("ChocolateyBinRoot") -eq $null)
{
    [Environment]::SetEnvironmentVariable("ChocolateyBinRoot", ($env:SystemDrive + "\tools"), "User")
    [Environment]::SetEnvironmentVariable("ChocolateyBinRoot", ($env:SystemDrive + "\tools"), "Process")
}

cinst sysinternals
Setting it at the "User" level is where it should normally be set, so this takes care of future instances of Powershell. Setting at the "Process" level takes care of this instance of Powershell. It seems like $env:ChocolateyBinRoot = "whatever" should be equivalent to setting at the "Process" level the long way, but I just can't get it to work for some reason.

I suppose that technically I should also be checking chocolatey_bin_root, but for this application our team will be using, it's highly unlikely that someone has chocolatey_bin_root and not ChocolateyBinRoot, so I'm not gonna bother.