-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FullName not working as it did in 2.19.3, seems to have broken in 2.20.0 #1859
Comments
@devnut Whats the actual issue you are facing ? |
Fullname() is returning "subcommand", not "command subcommand". The following equivalent code before version 2.20.0, it did. Example:
Output:
Contrast this with v2.19.3:
I could make HelpName work, but it seems to have changed too. If FullName() returned in 1.21 what it did in 1.20, that would be fine as the work-around we have for "foo" returning an empty string would continue to work, which involves using "HelpName".
|
@devnut Yes the FullName was actually buggy as you can see from your example. It wasnt consistent so FullName returns the name of the command and HelpName the display name in help. |
My urfave/cli version is
2.19.3
Checklist
Dependency Management
Describe the bug
In urfave 2.19.3 when calling FullName() it is constructed from c.commandNamePath.
In 2.19.3 there is code in startApp() that does not seem to be in 2.20.0-2.21.1
To reproduce
c.Command.FullName() (where c is *cli.Context of a subcommand)
Observed behavior
Only the "subcommand" name is printed
Expected behavior
FullName() would emit "command subcommand"
Additional context
Add any other context about the problem here.
Want to fix this yourself?
We'd love to have more contributors on this project! If the fix for
this bug is easily explained and very small, feel free to create a
pull request for it.
Run
go version
and paste its output hereRun
go env
and paste its output hereThe text was updated successfully, but these errors were encountered: