urfave
Unexpected args when using DefaultCommand
My urfave/cli version is
3.3.8
Checklist
- [x] Are you running the latest v3 release? The list of releases is here.
- [x] Did you check the manual for your release? The v3 manual is here
- [x] Did you perform a search about this problem? Here's the GitHub guide about searching.
Dependency Management
- My project is using go modules.
- My project is automatically downloading the latest version.
Describe the bug
When using the DefaultComment property on the root command, define a subcommand, and then run all that without specifying a command, it seems like the parser still tries to match the first argument to a subcommand. Within the subcommand's Action cli.Command.Args will simply not include the first argument.
To reproduce
I've collected some test cases here: https://github.com/zerok/issue-urfave-cli-v3-defaultcmd-args
Observed behavior
The first argument as seen from the subcommand's Action is not present when DefaultCommand is used and the command doesn't match.
Expected behavior
This should IMO either lead to an error or the parser checking the list of defined subcommands and warn if none could be matched and so the default command is used.
Additional context
Add any other context about the problem here.
If the issue relates to a specific open source GitHub repo, please link that repo here.
If you can reproduce this issue with a public CI system, please link a failing build here.
Want to fix this yourself?
I'm not completely sure if this is even a bug or just undocumented behavior. But if time permits and this is confirmed to be a bug, I'd like to work on this.
Run go version and paste its output here
go version go1.24.4 darwin/arm64
Ahhh I was trying to add a new issue very similar to this one, but it seems that whatever will be fixed by @Samarthasbhat, it should deal with my case as well.
Here is my descriptive example: I have a program called, say, compress. It compresses one file as its first argument, and if a second argument is given, that's the name of the output file. So far, so good; imagine, this is version 1 and straightforward to implement. User will execute ´compress myfile.txt mycompressedfile.ext(with some optional flags, say,--debug or ´--progress).
For version 2, there are now three compression levels, implemented as subcommands, each with extra flags pertaining just to that level. Imagine we call these subcommands standard, advanced, optimal. However, it's expected that most users will be happy with standard. Additionally, it would be nice to keep some backwards compatibility for those having incorporated version 1 in their scripts. Thus, standard is defined as DefaultCommand. The two argumentss are defined (and set) both at the top level and for each subcommand.
While compress standard myfile.txt mycompressedfile.ext will work exactly as expected, if standard is omitted, the two arguments (the filenames) have been "consumed" but remain unset.
By "consumed" I mean that, by the time the default command is run, those two arguments are somehow "lost". If I use cli.Args to retrieve any of them, they're empty strings. And if I check the values they were (presumably) auto-assigned, they're empty as well.
I would say this is pretty much the same issue as reported, with the difference perhaps that I have two arguments, neither of which get assigned anything.
@GwynethLlewelyn Can you share a snippet of your issue ? I've run the test code provided by @zerok https://github.com/zerok/issue-urfave-cli-v3-defaultcmd-args with latest release and the tests run fine.
https://go.dev/play/p/Tfor4H_DwSb
Oh, sure, as always, I forgot to link to the repository where I have a fork of the original project, which I'm encapsulating in a CLI and add some more bells and whistles: https://github.com/GwynethLlewelyn/tinify-go