Repository navigation
Function & Cmdlet Name Tab Completion Broken in the ConfigManager (CMSITE) Provider #20803
Description
Prerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
Summary
7.4.0 seems to have broken cmdlet & function name tab completion for all cmdlet & functions while the location is set to the Config Manager provider (CMSITE). This was working just fine in previous versions of PowerShell 7.
Scope
- Tab completion for cmdlet & function parameter names & values is not broken, even when the location is set to the
CMSITEprovider. - Cmdlet & Function name tab completion is not broken when the location is set to any of the built-in providers.
- I can reproduce this on multiple machines.
Workaround
Reverting back to a previous version of PowerShell, i.e. 7.3.10, fixes the issue.
Background Info
My version of the ConfigurationManager module shouldn't matter since reverting back to PowerShell 7.3.10 fixes the issue, but just in case I am using version 5.2303.1089.1000 of the module.
Setup Code
PS C:\> Import-Module ConfigurationManager
PS C:\> $SiteCode = Get-PSDrive -PSProvider CMSITE
PS C:\> Set-Location -Path "$($SiteCode.Name):\"
PS DCC:\> Get-Ite{Tab}
PS DCC:\> function Test-TabCompletion {}
PS DCC:\> Test-TabCompletio{Tab}
Expected behavior
PS DCC:\> Get-Item
PS DCC:\> Test-TabCompletionActual behavior
PS DCC:\> Get-Ite
PS DCC:\> Test-TabCompletioError details
No response
Environment data
Name Value
---- -----
PSVersion 7.4.0
PSEdition Core
GitCommitId 7.4.0
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.0Visuals
No response
Activity
MartinGC94 commentedon Nov 28, 2023
It's probably related to the change I made here: #19489 I don't have any way to test tab completion in that provider though. Can you try to CD into that provider and run this:
TabExpansion2 -inputScript Get-and post the full error details when it hopefully throws?alexlarner commentedon Nov 28, 2023
Here's the error details from that:
MartinGC94 commentedon Nov 28, 2023
Okay, it's probably failing here: https://github.com/PowerShell/PowerShell/blob/master/src/System.Management.Automation/engine/CommandCompletion/CompletionCompleters.cs#L4786 because it's somehow finding 2 items with the same name in a folder/container.
Can you run the following from that same location?
ls -LiteralPath .\ | select -ExpandProperty PSPathand see if the same path shows up twice in the results?Also, can you run this:
Get-PSProvider -PSProvider CMSITE | select -ExpandProperty ItemSeparatorand validate that the reported item separator matches the one you see for each item in that list?Finally, can you tell me if it includes the provider name in the pspath results from before? Like:
Microsoft.PowerShell.Core\FileSystem::C:\Users\Martin\.dotnetalexlarner commentedon Nov 29, 2023
ls -LiteralPath .\ | select -ExpandProperty PSPathAdminUI.PS\CMSite::[Config Manager Primary FQDN Redacted]\Get-PSProvider -PSProvider CMSITE | select -ExpandProperty ItemSeparator\CMSITEis included in all the PSPath entries aboveMartinGC94 commentedon Nov 29, 2023
Seems like the SCCM team misunderstood the purpose of the PSPath property in the provider system. The whole idea behind the provider system is that you can refer to objects by a path, similar to what you would do on a filesystem but obviously that can't work if the same path points to 21 different objects.
It would have been nice if this had been enforced from the start but I guess that ship has sailed so we'll just have to handle their mistake by ignoring duplicates. I'll create a PR to fix this later today.
alexlarner commentedon Nov 29, 2023
Thanks
MartinGC94 commentedon Nov 29, 2023
I've created the PR here: #20815 if you have the time feel free to download the Windows build that will get created as part of the automatic tests and then confirm that the changes I made actually fixed the issue for you.
alexlarner commentedon Dec 12, 2023
Sorry, for the late response, but that didn't seem to fix it.
And now when I try to run
TabExpansion2 -inputScript Get-, I get this error instead.I believe I downloaded the right build. I downloaded this.
MartinGC94 commentedon Dec 13, 2023
Thanks. I've found a premade SCCM lab by MS that I can download and test this on. Will investigate and try to fix it in the near future.
alexlarner commentedon Dec 13, 2023
The repo home page Windows link takes you to a
PowerShell-CI-windowspipeline, however there is also aPowerShell-CI-Windows-dailylisted under Pipelines. I didn't know which of those you were referring to, so I attempted to test the latest of both.I was able to download and run PR-20913-20231212.03 from the
PowerShell-CI-windowspipeline, and it had the same issueI couldn't get the latest two PowerShell-CI-Windows-daily builds to run as they were blocked from running by our company's Windows security.
iambdud commentedon Jul 17, 2024
I am still having this issue with 7.4.3. Was the change reverted?
MartinGC94 commentedon Jul 17, 2024
Looking at the 7.4 release branch, it doesn't seem like the fix has been added there: https://github.com/PowerShell/PowerShell/blob/release/v7.4/src/System.Management.Automation/engine/CommandCompletion/CompletionCompleters.cs#L4858 so I guess they've forgotten to backport it (assuming they will do that since it was a regression).
Hopefully they'll do that, but if not then I guess you'll just have to use 7.5
iambdud commentedon Jul 17, 2024
Thanks for the reply. I am using 7.5 in the meantime.
Sorry for my ignorance... but where did the fix go if it didn't make it into 7.4?
Edit: Ahh. I see now. It was merged into master but did not make it into Release.