Help text: Display argv[0] for root command by default #641
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #633 #570 #295
This seems like the "correct" default, although I'm sure there's some crazy edge case I'm failing to take into account. 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 becomeroot-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 seeUSAGE: 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.
Checklist