Skip to content

CLI: Ambiguous parameter names such as -no are misinterpreted as positional parameter values #4351

Closed

Description

Steps to reproduce

# -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)

Activity

  1. SteveL-MSFT commented on Aug 14, 2017

    @SteveL-MSFT
    Member

    -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.
    
  2. mklement0 commented on Aug 15, 2017

    @mklement0
    ContributorAuthor

    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.

  3. 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
  4. mklement0 commented on Aug 15, 2017

    @mklement0
    ContributorAuthor

    Steve Lee (@SteveL-MSFT): I just realized that even PowerShell's internal parameter parsing has inconsistencies - see #4576

  5. SteveL-MSFT commented on Aug 15, 2017

    @SteveL-MSFT
    Member

    I have a change that I think addresses your valid concern:

    PS> .\powershell.exe -no -file foo
    Invalid argument '-no', did you mean:
    
            -nologo
            -noexit
            -noprofile
            -noninteractive

    Need to add tests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions