-
Notifications
You must be signed in to change notification settings - Fork 8.2k
Ensure programmatic discoverability of parameters that support wildcard patterns #4716
Description
Related: #4715.
Currently, compiled cmdlets apparently don't reflect in their parameter metadata which parameters support wildcard patterns.
By contrast, advanced functions that have [SupportsWildcards()]-decorated parameters already do, at least with Get-Command.
Two distinct fixes are required, it seems:
-
Consistently decorate parameters of compiled cmdlets that support wildcard patterns with the
[SupportsWildcards()]attribute. -
Make sure that the output from
Get-Help -Parameterreflects that attribute.
Currently, whether a given compiled cmdlet's parameter supports wildcards must be gleaned from the help description.
# Get-Command:
# Attributes of the -Path parameter give no indication that wildcards are supported,
# even though they are.
> Get-Command Get-Item | % Parameters | % Path | % Attributes
Position : 0
ParameterSetName : Path
Mandatory : True
ValueFromPipeline : True
ValueFromPipelineByPropertyName : True
ValueFromRemainingArguments : False
HelpMessage :
HelpMessageBaseName :
HelpMessageResourceId :
DontShow : False
TypeId : System.Management.Automation.ParameterAttribute
# Get-Help:
# The only way to discover wildcard support is via Get-Help, via the parameter *description*.
# Note that the attributes *contradict* the description:
> Get-Help Get-Item -Parameter Path
-Path <String[]>
Specifies the path to an item. This cmdlet gets the item at the specified location.
Wildcards are permitted. # !! This is the ONLY indication that wildcards are supported.
This parameter is required, but the parameter name ("Path") is optional.
Use a dot (.) to specify the current location. Use the wildcard character (*) to specify all the items in the current location.
Required? true
Position? 1
Default value none
Accept pipeline input? true (ByValue, ByPropertyName)
Accept wildcard characters? false # !! Contradicts the above.
By contrast, advanced functions at least allow programmatic discovery via Get-Command:
function foo { param([SupportsWildcards()] $Bar) $Bar }
Get-Command foo | % Parameters | % Bar | Select-Object AttributesThe above yields:
Key Attributes
--- ----------
{__AllParameterSets, System.Management.Automation.SupportsWildcardsAttribute}However, using Get-Help -Parameter still doesn't reflect the attribute:
> Get-Help foo -Parameter Bar
-Bar <Object>
Required? false
Position? 0
Accept pipeline input? false
Parameter set name (All)
Aliases None
Dynamic? false
If you use comment-based help, however, the attribute is reflected, although the output format changes significantly:
<#
.SYNOPSIS
Short description
.DESCRIPTION
Long description
.EXAMPLE
Example of how to use this cmdlet
.EXAMPLE
Another example of how to use this cmdlet
#>
function foo { param([SupportsWildcards()] $Bar) $Bar }Note how wildcard support is now reflected [update: formerly, the output format would change in the presence of comment-based help, and the wildcard attribute was labeled "globbing"; this seems to be fixed as of at least PowerShell Core 7.1.0-preview.5]
> Get-Help foo -Parameter Bar
-Bar <Object>
Required? false
Position? 1
Default value
Accept pipeline input? false
Accept wildcard characters? trueEnvironment
PowerShell Core v6.0.0-beta.7