search

dotnet / command-line-api

Command line parsing, invocation, and rendering of terminal output.
https://github.com/dotnet/command-line-api/wiki
MIT License
3.35k stars 375 forks source link

dotnet tool install can return an incorrect error message #2404

Open JohnVottero opened 2 months ago

JohnVottero commented 2 months ago

Description

If you try to install a tool with a command like: dotnet tool install bad.tool.name you receive an error message of:

Cannot find a manifest file.
For a list of locations searched, specify the "-d" option before the tool name.
If you intended to install a global tool, add `--global` to the command.
If you would like to create a manifest, use `dotnet new tool-manifest`, usually in the repo root directory.

If you follow the suggestion in the message and add "-d", you get an error of: Unrecognized command or argument 'bad.tool.name'. That error is then followed by help text which doesn't mention a "-d" option. I have not found a way to get it to accept a "-d" option nor have I found a way to get it to list the locations searched.

Reproduction Steps

The steps to reproduce are part of the description.

Expected behavior

Adding "-d" would list each location searched when the command is searching for the tool manifest.

Actual behavior

No search location information is displayed and the suggested option is invalid.

Regression?

I don't know if this has ever worked.

Known Workarounds

No known workarounds.

Configuration

8.0.300-preview.24203.14

Windows 11 on x64

Other information

No response

baronfel commented 2 months ago

At one point we had a -d flag that wasn't reflected in the grammar of the commands directly - as a result I bet it was broken/regressed. We should at minimum update the error message here, and instead of -d the highest verbosity should list the probing paths.

Forgind commented 2 months ago

At one point we had a -d flag that wasn't reflected in the grammar of the commands directly - as a result I bet it was broken/regressed. We should at minimum update the error message here, and instead of -d the highest verbosity should list the probing paths.

That was my first thought, too, but it turns out this is being parsed wrong. System.CommandLine is generating this error, and we're just reporting it. I think it's because of something with not recognizing bad.tool.name as a real argument, then not finding anything else and erroring? But I'm not at all familiar with S.CL code, so I could easily be wrong on that.