Unable to include program name in generated Usage statement

[willnationsdev]

As far as I can tell, there is no way for me to inject a placeholder for the actual program name into the Usage instructions used by all of the commands.

If I have subcommands added, then the default help text produces a Usage line that looks something like this:

Usage: [command] [-h|--help] [--version]

If I run git -h on my terminal, the usage line actually includes the git command itself (and the subcommands likewise prefix themselves with the actual program name). I don't seem to be able to reproduce that kind of behavior.

usage: git [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
           [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
           [-p | --paginate | -P | --no-pager] [--no-replace-objects] [--no-lazy-fetch]
           [--no-optional-locks] [--no-advice] [--bare] [--git-dir=<path>]
           [--work-tree=<path>] [--namespace=<name>] [--config-env=<name>=<envvar>]
           <command> [<args>]

Perhaps there could be an assembly attribute folks could use to specify this? It should already be accessible from MSBuild's project properties though if people are using AssemblyName or ToolCommandName to specify the name of the executable.

[neuecc]

Instead, the commands and options sections are shown, so is that not enough functionality?
When the root command contains options, it becomes Usage: [command] [options...] [-h|--help] [--version] and the Options are displayed as a list.
There are infinitely many help formats for cli tool,
so I have no intention of flexibly reproducing all formats, and it's not possible to do so.

[willnationsdev]

Instead, the commands and options sections are shown, so is that not enough functionality?

Ah, no, sorry, that's perfectly fine. What I want is this:

If my project specifies <AssemblyName>myapp</AssemblyName> or <ToolCommandName>myapp</ToolCommandName>, then I would expect the usage line for the default help text with subcommands to be...

Usage: myapp [command] [-h|--help] [--version]

...instead of...

Usage: [command] [-h|--help] [--version]

And then a subcommand of greet, when it's help text is displayed, would likewise have a usage line like this:

Usage: myapp greet [options] [-h|--help] [--version]

...or whatever. The myapp bit, i.e. the name of the actual app, should be included in the help text at all times.

That's all this issue is about. I'm not advocating for endlessly supporting every feasible permutation of command breakdowns or anything like that, lol.

[dusrdev]

@willnationsdev Since git is the end program, it makes sense that they note it in the help text. But, it doesn't make sense for the framework to do this by default.

If you write a script with .NET 10 file-based apps, and the user runs it with dotnet run myapp.cs -- args it doesn't make sense to say that "myapp" is part of the args and it won't even parse correctly.

Also, the framework isn't coupled to an actual app per-say, it is entirely possible to use it as an embedded console inside other apps or whatever. So imagine you have a text box, in which you write arguments, and use ConsoleAppFramework to parse/execute based on those, in that process you are not specifying an app name, and including it in the help text will only confuse users.

I could understand making it an opt-into toggle, but defintely not a default thing...

[willnationsdev]

That's fine if it is an opt-in thing. I just couldn't see any way for me to actually achieve it as-is, and so I brought it up as an issue.