-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dotnet-suggest broken for multiple tools #1850
Comments
Related: #1777 Though this issue is more about the fact that if dotnet-suggest can't deal with an executable it shouldn't return anything. |
If my command-line app has a custom completion delegate that throws an exception, I want to see the exception so that I can fix it.
I expect that suggestions should go to stdout and any exceptions should go to stderr, keeping them separate. Does it not work like that? |
Sure, in this case adding a --debug flag could help with that.
No, it doesn't. Because dotnet-suggest cannot distinguish exceptions in the tool from normal output from the tool. Exceptions within dotnet-suggest are sent to stderr. The tool error is printed to stdout. Which especially when used in the context of a completion handler for a shell is particularly weird. |
If dotnet-suggest supported a --debug flag, how would I add that flag when I notice that suggestions don't work right? I suppose the easiest way would be to edit the shell function that runs dotnet-suggest. What prints the tool error to stdout? CommandLineBuilderExtensions.UseExceptionHandler prints the exception to stderr, and SuggestionStore.GetCompletions does not redirect stderr of the child process… but do the foreground color changes in ConsoleExtensions go to stdout anyway? The |
Just run
I don't know, and it really shouldn't matter. I'm quite sure that those tools simply don't use System.CommandLine at all, hence why dotnet-suggest doesn't do anything useful with them in the first place. However it should ignore non System.CommandLine tools entirely and not execute them. |
This looks like a bug. Exceptions should definitely not be printed to stdout. |
https://github.com/dotnet/efcore/blob/6e5612349c9d763c3986995b7538701ae788434e/src/dotnet-ef/Program.cs#L20-L35 uses Reporter, which writes to stdout. I'll file a separate issue for the redundant logic in ConsoleExtensions. |
It seems that this is more widespread than one might think though. In general though, any output from the tool that is to be autocompleted should be supressed for |
Some of these tools might be using a version of In the case of Better debugging support here would be useful. It should probably include some of the diagnostic approaches mentioned in #1085 (comment) and #1648. Related: #1771. |
dotnet-ef isn't written using System.CommandLine at all. Hence its even stranger that dotnet-suggest even picks it up as a supported completion target. |
Yeah, I'm curious about how it got registered. |
As far as I can tell it registered all already installed tools when I installed it. |
Aren't all global tools considered registered by default, thanks to GlobalToolsSuggestionRegistration? |
dotnet-suggest is broken for a lot of standard tools.
My current installed list (according to dotnet-suggest list):
For most of these, except dotnet-suggest and dotnet-grpc, there are any valid suggestions returned. Usually an exception happens.
It seems to me as if dotnet-suggest should catch any exceptions and all output from a tool and only report suggestions if there are any.
Printing the output from the tool completely breaks autocompletion functions for the existing shell shims, at least on zsh.
In general I don't think executing those tools to get completions is a good idea either. It seems that if a tool is not built using System.CommandLine it will inevitably try to make sense of the [suggest] command which doesn't exist.
Running
dotnet-suggest get -e
on those executables yields:dotnet-ef
dotnet-grpc-cli
security-scan
reportgenerator
The text was updated successfully, but these errors were encountered: