You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For the root command, this name is never actually part of a command; it's only used in the usage string.
You can of course override it manually, but you never know if the executable gets renamed.
In my understanding, it's common for the usage string to use the actual name the command was invoked with (i.e. argv[0] in C terms). And I also think that's the only appropriate default behavior.
The text was updated successfully, but these errors were encountered:
dcantah
added a commit
to dcantah/swift-argument-parser
that referenced
this issue
May 31, 2024
Fixes: apple#633apple#570apple#295
This seems like the "correct" default. If your root command had the same name
as the resulting binary you produce, this was never an issue, however if
your root command was named anything else, then the current Usage/help text was
kind of odd.
If you don't specify an explicit commandName in CommandConfiguration, we would
take the root command name and generate a command name for you out of hyphens.
So, `RootCommand` would become `root-command` and this is what would be displayed
in the usage text for `/path/to/cool-binary --help`, even though intuitively you'd
expect to see `USAGE: cool-binary`.
The current behavior was also strange for binaries that are classically invoked
via symlinks as the same thing would happen. In this case imagine the struct name
matched the actual binaries name, but because the symlink is what users actually
invoke you could end up seeing an unfamiliar name in help text regardless. Using
argv[0] solves most of these problems.
The downside here is a LOT of tests need to change. I went with foregoing the
new approach if the user explicitly provides a command name, so most of the existing
tests that check for exact string matches of help text either need to replace the
command name with the first argument of the binary that is running the test (xctest,
but it doesn't really matter what it is as I've added a helper to plop in the first
argument for all of these tests), or they need to define
CommandConfiguration(commandName: "name-we-want"). For any tests that implemented
ParsableCommand I mostly went with the latter to make as few changes as possible.
Given this seems like mostly a UX change, I hope this seems sane.
Signed-off-by: Danny Canter <[email protected]>
The command name of a (
Async
)ParsableCommand
is inferred from the name of the struct by default.For the root command, this name is never actually part of a command; it's only used in the usage string.
You can of course override it manually, but you never know if the executable gets renamed.
In my understanding, it's common for the usage string to use the actual name the command was invoked with (i.e.
argv[0]
in C terms). And I also think that's the only appropriate default behavior.The text was updated successfully, but these errors were encountered: