Description
Steps to reproduce
dotnet add foo bar
Expected behavior
'foo' is an unrecognized thingie
Actual behavior
Unrecognized command or argument 'bar'
Notes
@jonsequitur @livarcocc @wli3 I'm pretty sure this is an expected ambiguity in the current parsing model. The fix here is not immediately clear since we can interpret foo
as either the subject {the target project} or as the verb
to perform on the default subject. Perhaps we can use this item to brainstorm a bit.
I tend to agree that the original design, allowing the project path to be specified as an optional argument
to dotnet add
, sacrificed too much consistency for the sake of low verbosity. I don't think we want to break folks at this stage, however, so we should probably minimize the impact of this one-off on the overall codebase.
A solution here likely means that the parser can tell whether or not the element in foo
's position is a valid file path. If it is, treat it as the optional argument. Otherwise, treat it as the verb
.
Is there a simpler/less invasive path?
Activity
wli3 commentedon May 3, 2017
That means the parser will have dependency on the current state of the file system. We need to take it carefully.
Also, this kind of implicit approach is good for human, but it might not be a good thing on CI. BTW, do we have any data about how many human vs CI using CLI?
wli3 commentedon May 15, 2017
@piotrpMSFT any thoughts?
jonsequitur commentedon May 15, 2017
I think this may just be a matter of error messaging in the CLI code. In the context of this command, we can probably interpret this as meaning that the optional file path was not provided and give a clearer error message.
I wouldn't advocate validating against the files on disk during the parse, but rather afterward in the handling code. It will make the parse results nondeterministic. For example, if the file doesn't exist, we would interpret the argument as a verb and display something like