Repository navigation
powershell.exe still receives PSModulePath for pwsh when called indirectly #12997
Description
I know why this is happening given how #11057 was implemented. Is there any sort of workaround, other than explicitly resetting the PSModulePath in the Windows Powershell script?
Steps to reproduce
- Set up invocation of powershell.exe in some sort of non-PS tool. In my case, a post-action on a
dotnet newtemplate.
{
"actionId": "3A7C4B45-1F5D-4A30-959A-51B88E82B5D2",
"args": {
"executable": "powershell",
"args": "-File init.ps1 "
},
"manualInstructions": [{
"text": "Run 'init.ps1'"
}],
"continueOnError": false,
"description ": "Initializes something."
}
- Invoke the above from pwsh.
Expected behavior
powershell.exe has correct PSModulePath.
Actual behavior
powershell.exe still has PS7 values in PSModulePath.
C:\path\to\init.ps1 : C:\Users\nwe\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 (x86)\Microsoft SQL
Server\140\Tools\PowerShell\Modules\
Environment data
Name Value
---- -----
PSVersion 7.0.2
PSEdition Core
GitCommitId 7.0.2
OS Microsoft Windows 10.0.18363
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Activity
daxian-dbw commentedon Jul 10, 2020
Nick Wesselman (@nickwesselman) When you directly invoke
powershellfrompwsh, PS 7 has special logic to detect that you are about to launch Windows PowerShell and thus it strips off the PS 7 specific module paths from the environment variable when starting thepowershellprocess. But in your case, it's not PS 7 that startspowershell, butdotnet.exe.dontet.exeinherits the environment variables and so didpowershellwhen it starts.We can potentially always strip off the PS 7 specific module paths when starting a native executable, but it may cause a similar issue where people expect the PS 7 module paths to be there but not ... /cc Steve Lee (@SteveL-MSFT) Joey Aiello (@joeyaiello)
iSazonov commentedon Jan 16, 2021
I still don't understand why we need to use this variable as an external exclusive storage. Ideally, we would always use it as a source for additional custom paths and always add service paths internally. This approach seems to solve all problems of side-by-side coexistence in any combination of versions and in any nesting.
HeyItsGilbert commentedon Mar 29, 2023
Finally found this issue! So I've seen this with Choco.exe, and with some internal tools at work. I could try to manually set the module path, but this would mean patching up a ton of random tools. Not to mention having to warn folks of this edge case.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.