Powershell: Concatenated PSModulePath values for PS7 module paths

[robinmalik]

I'm seeing an oddity on one desktop whereby the two module paths for PS7 are concatenated rather than split by a comma and this results in modules not being loaded.

Steps to reproduce

[Environment]::GetEnvironmentVariable("PSModulePath", "Process") -split ';' | sort

Expected behavior

C:\Program Files\PowerShell\Modules\
c:\program files\powershell\7\Modules

Actual behavior

C:\Program Files\PowerShell\Modules\c:\program files\powershell\7\Modules

or in full:

C:\Users\Robin\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules\c:\program files\powershell\7\Modules;;C:\Program Files\WindowsPowerShell\Modules\;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;

• note the double ;;

Environment data

Name                           Value
----                           -----
PSVersion                      7.0.2
PSEdition                      Core
GitCommitId                    7.0.2
OS                             Microsoft Windows 10.0.19041
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[robinmalik]

I have resolved this, by ensuring that every path in the machine level PSModulePath setting was without trailing backslashes.

If I put the backslashes back in, it breaks again.

[vexx32]

That definitely sounds like a bug... can you check the results from the following two queries?

[Environment]::GetEnvironmentVariable('PSModulePath', 'User')
[Environment]::GetEnvironmentVariable('PSModulePath', 'Machine')

[robinmalik]

User is empty.

Machine is: C:\Program Files\PowerShell\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files\SharePoint Online Management Shell;C:\Program Files (x86)\NetApp\NetApp PowerShell Toolkit\Modules;C:\Program Files (x86)\Cisco\Cisco UCS Manager PowerTool\Modules;C:\ProgramData\Boxstarter;

As I said, if backslashes are present it seems to break things. Infact, if I edit the system/machine environment variables to add a single backslash like this:

then the output of [Environment]::GetEnvironmentVariable('PSModulePath', 'Process') -split ';'

becomes:

```C:\Users\Robin\Documents\PowerShell\Modules
C:\Program Files\PowerShell\Modules\c:\program files\powershell\7\Modules

C:\Program Files\WindowsPowerShell\Modules
C:\Windows\system32\WindowsPowerShell\v1.0\Modules
C:\Program Files\SharePoint Online Management Shell
C:\Program Files (x86)\NetApp\NetApp PowerShell Toolkit\Modules
C:\Program Files (x86)\Cisco\Cisco UCS Manager PowerTool\Modules
C:\ProgramData\Boxstarter
```

and [Environment]::GetEnvironmentVariable('PSModulePath', 'Machine') remains the same but backslash is present:

C:\Program Files\PowerShell\Modules\;C:\Program Files\WindowsPowerShell\Modules;C:\Windows\system32\WindowsPowerShell\v1.0\Modules;C:\Program Files\SharePoint Online Management Shell;C:\Program Files (x86)\NetApp\NetApp PowerShell Toolkit\Modules;C:\Program Files (x86)\Cisco\Cisco UCS Manager PowerTool\Modules;C:\ProgramData\Boxstarter;

[vexx32]

Yeah looks like we got some issues with how PS is concatenating existing environment variables and its own defaults for PSModulePath.

@SteveL-MSFT this might be something you wanna take a look at? 💖

[iSazonov]

I can not reproduce in latest build 7.1.

[robinmalik]

I'll test this on another machine, then upgrade PowerShell and try with that.

[robinmalik]

On a Windows 10 machine with PowerShell 7.0.1 and PowerShell 7.1 preview 5:

I then added C:\Program Files\PowerShell\Modules\ and the output of [Environment]::GetEnvironmentVariable('PSModulePath', 'Process') -split ';' became:

C:\Users\Administrator\Documents\PowerShell\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
C:\Program Files\PowerShell\Modules\c:\program files\powershell\7\Modules

Removing that entry then cleans that up:

C:\Users\Administrator\Documents\PowerShell\Modules
C:\Program Files\PowerShell\Modules
c:\program files\powershell\7\Modules
C:\Program Files\WindowsPowerShell\Modules
C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules

but of course WindowsPowerShell doesn't see modules installed into C:\Program Files\PowerShell\Modules.

Either way, it's fixed by removing that trailing \ from the path.

[iSazonov]

I can reproduce.

[anmenaga]

This may be related:
I've seen the double semicolon in PSModulePath on ARM-32 Windows 10 IoT Core in PS zip-based release package:

administrator@piiot C:\Data\Users\Administrator>.\PS710P5\pwsh
PowerShell 7.1.0-preview.5
Copyright (c) Microsoft Corporation.

https://aka.ms/powershell
Type 'help' to get help.

PS C:\Data\Users\Administrator> $psversiontable

Name                           Value
----                           -----
PSVersion                      7.1.0-preview.5
PSEdition                      Core
GitCommitId                    7.1.0-preview.5
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS C:\Data\Users\Administrator> $env:psmodulepath
C:\Data\Users\Administrator\Documents\PowerShell\Modules;C:\Program Files\PowerShell\Modules;c:\data\users\administrator\ps710p5\Modules;;
PS C:\Data\Users\Administrator>

[SteveL-MSFT]

The double semi-colon isn't related and is ok. I found the problem, basically the current code tries to detect if something like the user path is already in PSModulePath to append a different shared path. However, the comparison trims trailing whitespace and path separator, so the index being returned is off by any trimmed whitespace or path separator count. Working on a fix.