These should probably not be possible

Steps to reproduce

# Create a variable name that is nothing but spaces:
${ } = 'boo'
${ }

# Create a variable name that contains leading or trailing whitespace:
${   foo   } = 'bar'
$foo # Not found
Get-Variable -Name '   foo   ' -ValueOnly

# Create a function whose name contains leading whitespace (trailing whitespace is silently stripped)
New-Item 'function: foo ' -Value {'Whitespace only'}
& ' foo ' # Not found
& ' foo' # This works (the trailing whitespace was ignored during creation of the function)

# Create an alias whose name is nothing but whitespace
New-Alias -Name ' ' -Value Get-Date
& ' ' # Shows the date

# Set a breakpoint on a command that is just whitespace
Set-PSBreakpoint -Command ' '

# Try to trigger a breakpoint on that command
& ' ' # Does not work

# Set a breakpoint on a variable that is just whitespace
Set-PSBreakpoint -Variable ' ' -Mode ReadWrite

# Try to trigger a breakpoint on a variable whose name is nothing but whitespace
${ } # triggers breakpoint

# Create a filename in the current location that has leading and trailing whitespace in its name
New-Item ' huh.txt ' -Value 'Explorer does not allow such names to be created'

# Open the file in notepad
notepad ' huh.txt ' # works
notepad ' huh.txt' # also works even though the trailing whitespace was dropped
notepad 'huh.txt' # does not work; prompts to create a new file

Expected behavior

1. Command and variable names should either be trimmed so that they contain no extraneous whitespace, or they should raise an error if they contain extraneous whitespace so that there is no ambiguity on the part of the person creating the command or variable.

2. Set-PSBreakpoint should trim whitespace from string parameters.

Actual behavior

As indicated in the comments above.

How we might fix this

Define an AutoTrim attribute

This attribute would automatically trim string values before they are validated against validation attributes. That corrects the contents for commands, which is helpful; however, it means users can pass in values and get results that are different than those values (i.e. create an alias with leading/trailing whitespace and end up with alias that doesn’t have the whitespace). This could hide bugs that exist in calling code.

Define a ValidateNoExtraneousWhitespace attribute

This attribute would result in an error in the parameter binder if a parameter of type string or a parameter that is a collection of type string contained strings that included leading or trailing whitespace, forcing the caller to deal with the problem. This is my preferred partial solution to this issue.

Questions

Is there anything we can/should do about provider paths with leading/trailing whitespace? For PowerShell entities such as functions/aliases/variables, we can obviously generate errors if leading/trailing whitespace is used, but since files exist outside of PowerShell and can be created with spaces in Windows (not sure about macOS/Linux, haven’t tested there), we probably can’t provide a generic solution that prevents use of paths with extraneous whitespace.

Environment data

Name                           Value
----                           -----
PSVersion                      6.2.1
PSEdition                      Core
GitCommitId                    6.2.1
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.0

[KirkMunro]

@JamesWTruher The problem is that bugs and unexpected behavior shows up from these types of edge cases. It isn’t about telling you what you can/cannot use for variable/function/alias names. It is about ensuring there is some expectation of order though, so that you don’t run into obscure bugs or unexpected behavior that show up when you use names that are not expected. Such “restrictions” would help the scripter, not just in their use of PowerShell, but in being a scripter/developer in general.

On the flip side, if we don’t do this, do we have tests in place for such things (variable/function/alias names that are whitespace only or that start and/or end with whitespace), so that the scripter can reasonably expect them to work just fine? I’d wager that we don’t, and I think it would be better to guide PowerShell scripter here in the right direction than to spend time testing/fixing the engine so that it properly supports such things throughout the language.

A few well-intentioned limits here would be a good thing in my book.

[msftrncs]

@KirkMunro, you can use parameters that start like -32bit, just not via the - designator, they instead require using hashes and the splat operator, or using an invoke object with parameter hash and with a new method coming soon with @@{'32bit'=$true}.