USAGE command name should always reflect the actual binary name #295
Labels
bug
Something isn't working
Comments
|
Another common occurrence of this is running the executable via a symlink, where the symlink has a different basename to the executable it's pointing to. I guess |
smvz
added a commit
to smvz/swift-argument-parser
that referenced
this issue
Oct 4, 2022
This adds the `shouldUseExecutableName` property, allowing the command name to be derived from the executable's file name. The property defaults to false, both because subcommands using it is probably undesirable and to preserve existing behaviour after updating the package.
2 tasks
dcantah
added a commit
to dcantah/swift-argument-parser
that referenced
this issue
May 31, 2024
Fixes: apple#633 apple#570 apple#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 <danny@dcantah.dev>
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The default
USAGEoutput derives the usage command name from theParsableCommandtype name. Now this might be correct or not. The "correct" way would be to always use the last path component ofargv[0], as it would also show the correct string in case the build product name is different from the class name or the user renames the tool.While there is
_commandNameI can use to override this, it is marked as for internal use only.The text was updated successfully, but these errors were encountered: