Repository navigation
PowerShell Core doesn't inherit PSModulePath environment variable from the environment #6850
Description
Windows PowerShell correctly inherits environment variables from the environment -- although it may add paths to these variables, it doesn't ignore the existing environment.
PowerShell Core sets the PSModulePath -- completely ignoring and overwriting the existing environment, including the default values set in the Windows System Properties control panel...
This makes PowerShell Core's PSModulepath basically impossible to manage, since it can only be set reliably in a machine profile script --which depend on the install location of the shell, which changes with each release!!
Steps to reproduce
From Windows PowerShell run:
$Env:PSModulePath
pwsh -noprofile -command { $Env:PSModulePath }
pwsh -noprofile -command { powershell -noprofile -command { $Env:PSModulePath } }From pwsh run:
$Env:PSModulePath
PowerShell -noprofile -command { $Env:PSModulePath }Expected behavior
pwsh should respect it's environment.
Actual behavior
pwsh overwrites it's environment
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.2
PSEdition Core
GitCommitId v6.0.2
OS Microsoft Windows 10.0.17134
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Activity
SteveL-MSFT commentedon May 10, 2018
There's explicit code clearing the variable
Jaykul commentedon May 10, 2018
yes, but that code is based on the incorrect (or rather, outdated) assumptions that "The machine-wide and user-wide environment variables are only meaningful for full ps"
First of all, since PowerShell itself does not set those environment variables, there is no basis for this assumption. These are environment variables under the control of the user. You have no right to ignore them.
Second, as noted on #2636, many of the core modules do work. You've even released a module predicated on the fact that this is, in fact, not true 😉
We can't on the one hand claim that many (or most) modules will just work, and on the other hand say that the environment variable is so toxic that we can't trust users (and enterprises) to deal with it properly. Especially since this breaks all reasonable expectations regarding environment variables.
BrucePay commentedon May 10, 2018
Maybe we should have another environment variable
$ENV:PSModulePathCore. On startup, if PowerShell Core sees this variable, it uses it otherwise it falls back to$ENV:PSModulePath. With two variables, thenpowershellcan callpwshandpwshcan callpowershelland everything works. And eventually we can create aPowerShellCommonmodule directory for modules that work with both and that both variables include.Jaykul commentedon May 11, 2018
A separate
$Env:PSCoreModulePathenvironment variable kind-of makes sense.However, there are probably a lot of scripts and modules using
$Env:PSModulePath... I mean, at a minimum, people's profiles, and modules like PSDepend. Would you just read it and overwrite$Env:PSModulePath? Would that help?Could we rely on the modules themselves setting
CompatiblePSEditions, and let each version of PowerShell ignore modules that aren't compatible? (Actually, sure this wouldn't work, nevermind. Most of the modules that I'm concerned with are legacy modules which aren't going to be updated withCompatiblePSEditionany time soon, but which still work ... )Bear in mind that in the near future, the more frustrating problem is Windows PowerShell. As new modules come out which take advantage of PowerShell Core functionality, Windows PowerShell won't be able to use them, and it does inherit the environment variable, already.
BrucePay commentedon May 11, 2018
There are different profiles for desktop and core. You have to expend effort to get them to share common code and work properly. (e.g. no loading
winformassemblies in your Core profile). So you put edition-specific tweaks in the appropriate profile.Most scripts and modules depend on the module path being set correctly for the PS edition they are using. With separate variables, by default they will only load modules from the module directories associated with their shell edition. For things that work directly with PSModulePath, they'll have to be updated to understand PowerShell Core.
Without separate 'edition' directories, how do I have both "core" and "desktop" install paths for a given module/version? (Nuget does this with
<package>/<version>/lib/<editionEquivalent>but that would require changing both Core and Windows Powershell so it is unlikely to happen.)All the more reason to have separate module paths. I should be able to do
from
pwsh.exeand it should just work.SteveL-MSFT commentedon May 11, 2018
Separate env vars makes sense to me. I think Bruce Payette (@BrucePay)'s proposal makes sense to respect user defined env vars and keep existing behavior for compatibility reasons, although I would call it
PSCoreModulePathkilasuit commentedon May 16, 2018
Separate env vars doesn't make sense to me
but neither was the decision to overwrite the existing 1 on pwsh loading, although I can understand WHY it happened, it doesn't mean I agree that the decision was the right course of action either back then or now going forward.
I'd personally opt for reverting the explicit code that changed this as IMO this wasn't an ideal change to make
Otherwise you'd need to change pwsh and a number of other tools, like PowerShellGet to have more unneeded points of complexity where reverting this would in my opinion make much more sense going forward
SteveL-MSFT commentedon May 16, 2018
@PowerShell/powershell-committee reviewed this and agrees that this issue warrants an RFC. Bruce Payette (@BrucePay) has offered to author the RFC.
iSazonov commentedon Jan 15, 2019
Steve Lee (@SteveL-MSFT) Taking in account #8635 could you please force the RFC?
SteveL-MSFT commentedon Jan 18, 2019
I believe Bruce Payette (@BrucePay) still plans to author this
BrucePay commentedon Jan 18, 2019
Steve Lee (@SteveL-MSFT) Joey Aiello (@joeyaiello) The existing RFC PR is here: PowerShell/PowerShell-RFC#133 Perhaps we can discuss this in the next committee RFC meeting on Monday.
morsley commentedon Aug 6, 2019
Any update to where this is at? Just re-installed pwsh on a machine and it clobbered my psmodulepath for Windows powershell which broke psreadline - immediately noticeable.
marcinsmialek commentedon Aug 6, 2019
While this isn't the solution to this problem, this may be a handy workaround, at least it's how I deal with this issue right now:
From PowerShell Core:
iSazonov commentedon Aug 6, 2019
#10300 is pulled to resolve the issue and others based on PowerShell Committee conclusion.
MarcoPeraza commentedon Oct 9, 2022
This is broken again, at least on insider builds and latest versions of pwsh.
bedesv commentedon Apr 15, 2024
I'm getting this issue with Get-FileHash on Powershell Core v7.4.2.
Line causing the error:
powershell -c "foreach ($file in Get-ChildItem '%TARGET_LOCATION%') { Get-FileHash -Algorithm MD5 $file.FullName }"potatoday commentedon Feb 19, 2025
Can't even compute a hash. I see the problem. Powershell is run by committee. Just like MS altogether these days, fix something break something else.