Repository navigation
Powershell Framework is broken (again) under Powershell Core #18108
Description
Activity
NOTICE THE
cmd.exeLAYER SANDWICHED IN THE MIDDLE. THIS IS NECESSARY TO MANIFEST THE BUG.Please re-check with latest 7.2.6 version and latest 7.3 Preview.
Ilya (@iSazonov) just tried it, it repos on both.
What's odd is
> (get-module Microsoft.PowerShell.Utility).exportedCommands.keys | where {$_ -like "Get-*"} Get-Alias Get-Culture Get-Date Get-Event Get-EventSubscriber Get-FormatData Get-Host Get-Member Get-PSBreakpoint Get-PSCallStack Get-Random Get-Runspace Get-RunspaceDebug Get-TraceSource Get-TypeData Get-UICulture Get-Unique Get-VariableGet-FileHashhas gone missing. It's there in Pwsh and PowerShell.exe normally, but not if one follows the stepsThat looks like a fun bug. Does
Get-FileHashdepend on some environment implementation likeGet/Set-Clipboardonxclip? Maybe putting cmd in the middle causes the environment variables to get messed up?Get-FileHashid binary cmdlet in pwsh and script in Windows PowerShell. This says WinPS doesn't load Microsoft.PowerShell.Utility module in right way.Root of the issue both PowerShell modify PSModule environment variable to insert version specific paths.
Obviously, this leads to conflict. While pwsh uses tricks to fix this WinPS knows nothing about it and works the same old way. Also pwsh cannot apply its tricks if it do not call WinPS directly.
There have already been a few PRs made around this. Each time with different tricky bugs. There will probably be more attempts until a move is made to eliminate the conflict at the root.My suggestion was to abandon this practice (modify PSModule), but MSFT team says it will break some scenarios, but doesn't say which ones - apparently it's their big secret :-)
Reacted by AssortedBitsSeems the Issue template managed to get broken on this issue
As a workaround, you can import WinPS compatible 'Microsoft.PowerShell.Utility' which contains 'Get-FileHash' function:
Import-Module $PSHOME\Modules\Microsoft.PowerShell.Utility -Function Get-FileHash
This can be run at the top of the script.
Reacted by AssortedBits and nannersAs a workaround, you can import WinPS compatible 'Microsoft.PowerShell.Utility' which contains 'Get-FileHash' function:
Import-Module $PSHOME\Modules\Microsoft.PowerShell.Utility -Function Get-FileHash
This can be run at the top of the script.
For anyone having this crop up while using scoop (CLI or via WinGet UI, etc.) add that Import-Module command at the top of
%SCOOP_DIR%\apps\scoop\current\lib\install.ps1and carry on without frequent hash check failures.The team auto-closes bugs with "no activity" as measured by comments. But this ticket has had multiple recent references from other bugs recently. Seems to me those should count as well as comments.
4 remaining items
(not completed, but won’t let me reopen)
Reacted by Christopher WarringtonThis issue wasn't resolved, could it please be re-opened by someone with appropriate permissions?
Reacted by AssortedBitsThis issue wasn't resolved, could it please be re-opened by someone with appropriate permissions?
Joffrey Bion (@joffrey-bion) did you hit "The PSModulePath Problem", as described above? If so, the problem is environmental, not inside pwsh. If you hit some different problem, you probably need to open a new Issue.
This issue wasn't resolved, could it please be re-opened by someone with appropriate permissions?
@joffrey-bion did you hit "The PSModulePath Problem", as described above? If so, the problem is environmental, not inside pwsh. If you hit some different problem, you probably need to open a new Issue.
Dan Thompson (@jazzdelightsme) Happened with a clean, out-of-the-box env, as that comment you linked to also states can happen when there is an intervening
cmdlayer between pwsh and powershell. So, this is an actual design problem with either pwsh or powershell, until MS states in its documentation somewhere that they do not support running the latter under the former.Reacted by Joffrey BionYes, sorry I forgot to reply. It is indeed a
PSModulePathproblem for me, but I never set this env var myself. So I do consider it a problem with Powershell, and more specifically pwsh+Powershell combination.If the env is not compatible, I would expect the 2 tools to use different variables for their respective environments.
AssortedBits - whilst this and #27774 are essentially the same issue, I am going to mark this one as as duplicate of that one, as the title on that is easier for us in coming back to and is more likely to be found in future & whilst I know that may seem like "Issue
This is my comment in that issue & please follow that one for further updates.
My question always when I see this sort of thing (irrespective of the PowerShell vs pwsh) is where is the benefit in the multiple layered approach going to
grandchild/great-granchild/great-great-granchildetcUsing Start-Process as opposed to direct calling of the python executable may help here with the -UseNewEnvironment parameter (not tested this as I don't have a python install to hand)
I don't think we could do anything in this codebase to aid with
pwsh -> other executable/s -> powershellother than perhaps provide guidance which would be docs updates.
Prerequisites
Steps to reproduce
Actual behavior
Error details
Environment data
Visuals
No response