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

Usage root command does not display `ToolCommandName` #2365

Open barrygiles opened 3 months ago

barrygiles commented 3 months ago

Using version 2.0.0-beta4.24126.1

The default help display does not reflect the tool name when installed as a .NET tool.

Related to https://github.com/dotnet/command-line-api/issues/403 and https://github.com/dotnet/command-line-api/issues/682, but there is no possibility to workaround this as the Name property now has no setter.

Ideally it would show either the project name or the .NET tool name, depending on how it is invoked.

Currently, it appears to use Environment.GetCommandLineArgs()[0] to get the command name. However, when executed as a .NET tool this seems to resolve to the underlying DLL (assuming the .NET tool exe is just a wrapper) and does not include the name of the tool.

Example: bar.exe installed as foo .NET tool

dir %USERPROFILE%.dotnet\tools\ foo.exe

Invoking through .NET tool C:\foo args Environment.GetCommandLineArgs() C:\Users\.dotnet\tools.store\\bar.dll

Usage: bar ...

KalleOlaviNiemitalo commented 3 months ago

I wonder if it would be possible to change .NET Runtime to use the original argv[0] of the process as Environment.GetCommandLineArgs()[0]. According to the documentation, "The first element is the executable file name", which does not promise that the string would always include a directory path. IIRC, on Windows, the Service Control Manager can place the service name there; and on GNU/Linux, argv[0] could have a - prefix if the application is being used as a login shell. It would be good to let the application read this information.

However, because .NET Core 1.0 already set the assembly path as the first array element, there must now be applications that expect it to keep working that way. Perhaps then, the safest fix would be to add new Environment.ProcessInvocationName API as an alternative of the existing Environment.ProcessPath. Related issues: https://github.com/dotnet/runtime/issues/30212, https://github.com/dotnet/runtime/issues/11305.