Chocolatey does not recapture PATHs modified by external installer

[Iristyle]

Neither cmd, nor Powershell will ever refresh their local copies of environment variables.

This is problematic for a couple of reasons

• The chocolateyInstall.ps1 may need access to tooling that is now a part of PATH
• The existing Powershell session must be closed, then reopened to use something that was just installed

The problem here is that Powershell does not "recapture" the environment variables once a session has been started.

So PATH could be modified, after running an installer, but Chocolatey cannot gain access to these without using the .NET System EnvironmentVariable APIs or manually accessing the real location in the registry -- i.e..

(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' -Name Path).Path

IMHO, what needs to be done is that the environment needs to be refreshed after a given installer wraps up.

I think that it makes sense to do the recapture after an install runs.

https://github.com/chocolatey/chocolatey/blob/master/src/helpers/functions/Install-ChocolateyPackage.ps1#L63

To recapture any changes made to PATH by external processes.

$Env:PATH = (@(,[Environment]::GetEnvironmentVariable('PATH', 'Machine') -s
plit ';') + @([Environment]::GetEnvironmentVariable('PATH', 'User') -split ';') | Select -Unique) -join ';'

[ferventcoder]

Command is a bit harder, but for powershell you suggested the following:

Env:PATH = (@(,[Environment]::GetEnvironmentVariable('PATH', 'Machine') -s
plit ';') + @([Environment]::GetEnvironmentVariable('PATH', 'User') -split ';') | Select -Unique) -join ';'

[ferventcoder]

#134

[ferventcoder]

It's in issue #134

[Iristyle]

So I have a couple of questions

• Is this the most appropriate spot in the codebase to do the environment refresh?
• Would it make sense to do a full environment refresh? (there may be other variables that these new tools need)
• Are there are any potential perm issues?

[Iristyle]

That PoshCode snippet is craziness... let me (manually) see if it actually works ;0

[ferventcoder]

How do you do a full environment refresh? I would love for that to happen with both powershell and command...

[Iristyle]

I can think of 2 ways to do this.. not sure on security implications.

• Iterate the registry to get all the environment variable names (it wouldn't simply be good enough to look at the names in the current session, because the list could have additions or removals)
• Launch a new PS session, capture the environment variable state there, and push it back to the initiating session (probably on the slow side)

[ferventcoder]

Install-ChocolateyPath actually pushes the new path...perhaps we can emulate that a bit.

[ferventcoder]

But it won't carry all the way back to the command line. That's what I'm hoping that crazy poshcode will do.

[Iristyle]

Ok -- just tried the PoshCode sample...

• Started a session
• Manually tweaked my PATH variables in control panel
• Opened a new session -- verified changes are in new session
• Verified changes are not in old session
• Ran crazy PoshCode

Original session does not have the new PATH

So in short, no go.

[ferventcoder]

Boo...

[Iristyle]

So if you want to get the keys

#user
Get-Item HKCU:\Environment | Select -ExpandProperty Property

#machine
Get-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' | Select -ExpandProperty Property

[mwrock]

I think this might work. Assuming new_var is the environment variable set.

Get-WmiObject Win32_Environment | where-object -filter {$_.Name -eq 'new_var'} | select VariableValue

[Iristyle]

Yeah, except how do you know what new_var is if an MSI just ran and added some new stuff? ;0

[ferventcoder]

Need both powershell and cmd shell versions...

@mwrock we'd need to iterate over all of them.

[mwrock]

Yup. You would have to build a list before the install and then do a delta.

[Iristyle]

For cmd -- fun!

http://stackoverflow.com/a/11147132/87793

[ferventcoder]

Command line - (it's ugly) - http://stackoverflow.com/questions/171588/is-there-a-command-to-refresh-environment-variables-from-the-command-prompt-in-w

[ferventcoder]

HA! We found the same article!

[Iristyle]

I have used those reg tools before, but I cringe every time I see that old DOS batch style pattern matching stuff. I think the cmd guys had Larry Wall aspirations.

[Iristyle]

I think the biggest issue then is the security considerations. As long as I can get to HKLM, the Powershell refresh is pretty straightforward.

[Iristyle]

I also need to double check the rules for environment -- i.e. we know that PATH is special cased to munge Machine and User -- but not sure if any other variables are treated specially.

I believe that User variables override Machine variables when the names overlap and there is no special casing like for PATH. Will try a few tests here to be sure.

[Iristyle]

Verified - User overrides Machine.

I gave PATHEXT a shot since it has a similar format to PATH. When I defined a User variant, it totally ate the Machine variant.

So unless someone has a definitive resource somewhere about this -- I'm going to assume that only PATH has special treatment.

[rismoney]

say i wrote a helper chocolatey-restart that simply closes the active session and reopens a fresh posh. is this invasive? would it work?

another random thought-maybe wmi event consumers can track the change to env vars...

[mwrock]

I played with some ideas today and I think I found a way to make this work for all env vars in ps and cmd with little batch ugliness. The gist of it is this. I'd have a Refresh-Environment.ps1 and RefreshEnvironment.bat. The ps1 would do something like:

$newVars=(powershell -outputformat xml -command "Get-WmiObject Win32_Environment | select Name, VariableValue")

What I foud is that you have to either use WMI or go directly to the registry and from a different process. Then it would use the xml api to build a PS dictionary of the environment variables that propperly resolves the system and user variables and does spacial handling on the path via concatenation. Finally it iterates the dictionary and flushes it to the env:\ drive. Then it outputs

gci env:

to standard output.

The bat calls the ps1 and flushes it to a file via >> and uses the

FOR /F "tokens=2,3* delims= " %%i in (vars.txt) do SET %i=%j

Based on some prototype tests, I think this works. I plan to extract this into a separate chocolatey/repo since I think it has usage scenarios outside of chocolatey. The snippits above might not be syntactically perfect but hopefully you get the idea. Hopefully I can get to this before the end of the weekend. Thoughts?

[ferventcoder]

I'm down for it if it works. :D

[Iristyle]

I just cooked this up and it works just fine -- no separate process or WMI necessary (I tend to avoid WMI because its just a wrapper on top of other stuff -- with the ability to fail due to DCOM issues, etc)

This is for Powershell only, not cmd.

https://gist.github.com/3732568

[mwrock]

Very nice. Plugged that into my test simulator and it works. I think adding the batch compatibility should be straight forward by having this output the new vars to std out and then having a .bat call that and taking the FOR strategy I mentioned above.

[Iristyle]

I'm just about done with a pull req.. just trying to get the unit tests to run under your test suite properly.

Will kick it off just so you guys can have a look, but don't pull it quite yet ;0

[Iristyle]

Also note that I may have the wrong spot for integration into Chocolatey.. I'll let you guys sort that part out if it's in the wrong spot.

Iristyle@8515ce2#L0R63

[mwrock]

Yeah I think this should probably go into Chocolatey-Nuget instead of Install-ChocolateyInstallPackage so it can be applied to all install scenarios.

[Iristyle]

Roger that -- will fix.

[Iristyle]

Pull updated with tests that work properly now...

[mwrock]

Great job! I'll add in the batch file version later unless someone else beats me too it.

[mwrock]

I'm closing this since it was essentially fixed with fd8b079. That should allow chocolatey (but not the caller) to use paths set by installers. There is another issue for the caller: #134