Powershell: Get-Command doesn't properly recognize System.Management.Automation.CommandInfo (its own output type) as pipeline input

[mklement0]

10851 reported that feeding Get-Command output to itself via the pipeline - useful if you want to force loading of all modules in the context of reflection, for instance - doesn't work as expected.

10929 tried to fix that, but fell short.

Steps to reproduce

function foo {}; set-alias foo foo

(gcm -all foo | gcm).Count | Should -Be 2

(gcm -all foo | gcm).ComandType | Should -Be Alias, Function

Expected behavior

The tests should succeed.

Actual behavior

The tests fail:

Expected 2, but got 278                   #  *all* commands are returned
Expected @('Alias', 'Function'), but got $null

Environment data

PowerShell Core 7.0.0-preview.5, with PR #10929 applied

[SteveL-MSFT]

So what's happening is that the foo function doesn't have a Noun or Verb (they are empty strings), but it does have a Noun and Verb property, so when it's piped to gcm it binds to -Noun and -Verb, since they are empty string, gcm does a wildcard search thus returning everything. A simpler repro:

function foo{}; gcm foo | gcm

Adding a new parameterset to accept CommandInfo won't help as the default parameter set is Noun/Verb which will match any CommandInfo object.

A possible fix would be if Noun and Verb are both empty, inspect the pipeline object further and use whatever is available to match: Name and CommandType

[vexx32]

Given there is currently no pipeline parameter accepting this object as input in its complete form, would that information be available to Get-Command?

[SteveL-MSFT]

@vexx32 excellent point, it wouldn't as only Noun and Verb would be there. Hmmm, I guess the only way to fix this I can think of is a breaking change so that CommandInfo parameterset is default.

[mklement0]

@SteveL-MSFT: It's fine to leave the default parameter set as-is - a specifically CommandInfo-typed parameter would still bind correctly.

[SteveL-MSFT]

@mklement0 it would bind correctly if the default parameter set doesn't bind first which it will

[mklement0]

@SteveL-MSFT

It doesn't _necessarily_ bind first, but, as I just realized, it does if you combine it with a parameter _not_ supported in a potential new CommandInfo-typed parameter set.

So the choices are:

• (a) change the default parameter set

• (b) make the new parameter set support _all_ other parameters (except -Name), even though some combinations don't make sense (such as -UseFuzzyMatching).

I'm unclear on the ramifications of (a)

(b) could be addressed by either warning about inapplicable arguments or throwing an error (there's already one instance of that in the existing code).

[SteveL-MSFT]

Changing the default parameter set makes the most sense to me, but also unclear how many will be impacted.

[iSazonov]

We could add optional parameter -Name in the default parameter set.