Skip to content

Ensure programmatic discoverability of parameters that support wildcard patterns #4716

@mklement0

Description

@mklement0

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 -Parameter reflects 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 Attributes

The 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?  true

Environment

PowerShell Core v6.0.0-beta.7

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-Code Cleanupthe issue is for cleaning up the code with no impact on functionalityResolution-No ActivityIssue has had no activity for 6 months or moreWG-Cmdlets-Corecmdlets in the Microsoft.PowerShell.Core module

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions