Powershell: Windows PowerShell inherits PSModulePath from PowerShell Core

[joeyaiello]

If you start Windows PowerShell from PowerShell Core, you get the $env:PSModulePath from PowerShell Core.

In my opinion, this should be a 6.0.0 blocker. Also, if any work needs to be done in Windows PowerShell to fix this, we should do it ASAP.

Steps to reproduce

From PowerShell Core:

Start-Process powershell

This will open a new instance of Windows PowerShell. From this instance:

$env:PSModulePath

Expected behavior

C:\Users\jaiello\Documents\WindowsPowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

Also, PSReadline should load.

Actual behavior

C:\Users\jaiello\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\program files\powershell\6.0.0.12\Modules

Also, PSReadline doesn't load because it can't be found.

Environment data

For PowerShell Core:

Name                           Value
----                           -----
PSVersion                      6.0.0-alpha
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
GitCommitId                    v6.0.0-alpha.12
CLRVersion
BuildVersion                   3.0.0.0
PSRemotingProtocolVersion      2.3
PSEdition                      Core
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}

For Windows PowerShell;

Name                           Value
----                           -----
PSVersion                      5.1.14931.1000
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.14931.1000
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

[iSazonov]

It is expected because subprocess always inherits environment variables of parent process. If we change the default behavior it can confuse users.
We would backup PSModulePath on startup and restore before create subprocess. Or create $env:PSModulePath_Backup and check it on PowerShell startup. The second is seems easier.

[SteveL-MSFT]

Agree with @iSazonov this is by-design as child processes are expected to inherit environment from parent. The way to address this may be to have PSModulePath in https://github.com/PowerShell/PowerShell-RFC/blob/master/1-Draft/RFC0015-PowerShell-StartupConfig.md

[joeyaiello]

I understand why it happens, but I think our story for side-by-side Windows PS/PS Core could be dependent upon this not being obtuse if Standard 2.0 doesn't provide the level of compatibility we need. It's just non-obvious to people.

[iSazonov]

Then the only way is to abandon the environment variable to both versions and use a global variable from the configuration file(s).

[joeyaiello]

I wouldn't say the only way, but yes that's how I would naively implement it. You could also query the machine env variable in other ways.

Either way, I didn't mean to imply we should update this right now. It's just important that we revisit it as compat testing for 2.0 progresses. We have to optimize for the glide path from Windows PS to PS Core.

[iSazonov]

Mark the Issue with Wait-NetStandard20?

Still the only ways :-)

• add PSModulePathCore
• use core path prefix in PSModulePath: "c:temp; core:c:powershellCoreModules"

[joeyaiello]

Adding label to reassess after we analyze FullCLR/CoreCLR compat

[SteveL-MSFT]

Perhaps we could consider having PSModulePath defined in StartupConfig instead of a different env var if we go down the breaking change path

[SteveL-MSFT]

This should be an RFC

[SteveL-MSFT]

@joeyaiello now that we can use many Windows PowerShell modules from within PSCore6, I'm moving this out of 6.0.0-HighPriority

[iSazonov]

@joeyaiello @SteveL-MSFT Seems we resolved the Issue in 6.1.0. Can we close?