You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CLI: Ambiguous parameter names such as -no are misinterpreted as positional parameter values #4351
# -no is ambiguous: could be -NoProfile, -NoLogo, ...
powershell -no -command get-date
Expected behavior
An error complaining about the ambiguity of the parameter name and refusal to continue.
Actual behavior
PS Core and Windows PS behave differently, due to the recent Core change to default to -File instead of -Command:
PowerShell Core:
The argument '-no' to the -File parameter does not exist. Provide the path to an existing '.ps1' file as an argument to the -File parameter.
PowerShell v6.0.0-beta.4
Copyright (C) Microsoft Corporation. All rights reserved.
Windows PowerShell:
-no : The term '-no' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.
At line:1 char:1
+ -no -command get-date
+ ~~~
+ CategoryInfo : ObjectNotFound: (-no:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Environment data
PowerShell Core v6.0.0-beta.4 on macOS 10.12.5
PowerShell Core v6.0.0-beta.4 on Ubuntu 16.04.2 LTS
PowerShell Core v6.0.0-beta.4 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.413 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
-no might be a valid script file, so I don't think we want check against ambiguous intended parameters (-Command didn't do this either). However, we can improve the error message. How about:
-no : The term `-no` is not recognized as a valid script file. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again.
For consistency and predictability, you should never assume that --prefixed tokens are parameter values, unless they follow a recognized, unambiguous parameter name (such as -Command):
If a positional token looks like a parameter name - i.e., if it starts with - followed by a letter - it should be interpreted as such.
If that parameter name is not recognized / cannot be resolved unambiguously, an error should occur, just as would happen inside PowerShell with something like get-item -f *.txt (Get-Item : Parameter cannot be processed because the parameter name 'f' is ambiguous. Possible matches include: -Filter -Force.).
By contrast, if a positional parameter value happens to start with - (e.g., a script file named -no), it is the user's responsibility to prefix it with an explicit parameter name in order to disambiguate: -File -no.
changed the title [-]CLI: Ambiguous option names such as -no are misinterpreted as positional parameters[/-][+]CLI: Ambiguous parameter names such as -no are misinterpreted as positional parameter values[/+]on Aug 15, 2017
Activity
SteveL-MSFT commentedon Aug 14, 2017
-nomight be a valid script file, so I don't think we want check against ambiguous intended parameters (-Commanddidn't do this either). However, we can improve the error message. How about:mklement0 commentedon Aug 15, 2017
Steve Lee (@SteveL-MSFT):
For consistency and predictability, you should never assume that
--prefixed tokens are parameter values, unless they follow a recognized, unambiguous parameter name (such as-Command):If a positional token looks like a parameter name - i.e., if it starts with
-followed by a letter - it should be interpreted as such.If that parameter name is not recognized / cannot be resolved unambiguously, an error should occur, just as would happen inside PowerShell with something like
get-item -f *.txt(Get-Item : Parameter cannot be processed because the parameter name 'f' is ambiguous. Possible matches include: -Filter -Force.).By contrast, if a positional parameter value happens to start with
-(e.g., a script file named-no), it is the user's responsibility to prefix it with an explicit parameter name in order to disambiguate:-File -no.[-]CLI: Ambiguous option names such as -no are misinterpreted as positional parameters[/-][+]CLI: Ambiguous parameter names such as -no are misinterpreted as positional parameter values[/+]mklement0 commentedon Aug 15, 2017
Steve Lee (@SteveL-MSFT): I just realized that even PowerShell's internal parameter parsing has inconsistencies - see #4576
SteveL-MSFT commentedon Aug 15, 2017
I have a change that I think addresses your valid concern:
Need to add tests