Skip to content
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

Closed
devnut opened this issue Jan 19, 2024 · 3 comments
Closed
Labels
area/v2 relates to / is being considered for v2 kind/bug describes or fixes a bug status/triage maintainers still need to look into this

Comments

@devnut
Copy link

devnut commented Jan 19, 2024

My urfave/cli version is

2.19.3

Checklist

  • [yes] Are you running the latest v2 release? The list of releases is here.
  • [yes] Did you check the manual for your release? The v2 manual is here
  • [yes] 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 using vendoring.
  • My project is automatically downloading the latest version.

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 here

go version go1.21.3 darwin/arm64

Run go env and paste its output here

GO111MODULE='auto'
GOARCH='arm64'
GOBIN='/Users/gsaylor/repos/bitbucket/everything_app/rapid_risk_assessment/bin'
GOCACHE='/Users/gsaylor/Library/Caches/go-build'
GOENV='/Users/gsaylor/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/gsaylor/go/pkg/mod'
GONOPROXY='hq-stash.corp.proofpoint.com'
GONOSUMDB='hq-stash.corp.proofpoint.com'
GOOS='darwin'
GOPATH='/Users/gsaylor/go'
GOPRIVATE='hq-stash.corp.proofpoint.com'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.21.3'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/Users/gsaylor/repos/bitbucket/everything_app/rapid_risk_assessment/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/73/p9_stkcx307dnz9y_qg4ydlr0000gp/T/go-build2092070924=/tmp/go-build -gno-record-gcc-switches -fno-common'
@devnut devnut added area/v2 relates to / is being considered for v2 kind/bug describes or fixes a bug status/triage maintainers still need to look into this labels Jan 19, 2024
@dearchap
Copy link
Contributor

@devnut Whats the actual issue you are facing ?

@devnut
Copy link
Author

devnut commented Jan 28, 2024

Fullname() is returning "subcommand", not "command subcommand". The following equivalent code before version 2.20.0, it did.

Example:


package main

import (
	"fmt"
	"log"
	"os"

	"github.com/urfave/cli/v2"
)

func main() {
	app := &cli.App{
		Name:  "boom",
		Usage: "make an explosive entrance",
		Commands: []*cli.Command{
			&cli.Command{
				Name:  "foo",
				Usage: "foo I say",
				Action: func(c *cli.Context) error {
					fmt.Println("foo! I say!")
					fmt.Printf("expecting '%s', bot got FullName() '%s', HelpName '%s'\n", "foo", c.Command.FullName(), c.Command.HelpName)
					return nil
				},
				Subcommands: []*cli.Command{
					&cli.Command{
						Name:  "bar",
						Usage: "bar I say",
						Action: func(c *cli.Context) error {
							fmt.Println("bar! I say!")
							fmt.Printf("expecting '%s', bot got FullName() '%s', HelpName '%s'\n", "foo bar", c.Command.FullName(), c.Command.HelpName)
							return nil
						},
					},
				},
			},
		},
	}

	if err := app.Run(os.Args); err != nil {
		log.Fatal(err)
	}
}

Output:

$ go get github.com/urfave/cli/v2
go: upgraded github.com/urfave/cli/v2 v2.19.3 => v2.27.1

$ go run main.go
NAME:
   boom - make an explosive entrance

USAGE:
   boom [global options] command [command options]

COMMANDS:
   foo      foo I say
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --help, -h  show help


$ go run main.go  foo
foo! I say!
expecting 'foo', bot got FullName() 'foo', HelpName 'boom foo'

$ go run main.go  foo bar
bar! I say!
expecting 'foo bar', bot got FullName() 'bar', HelpName 'boom foo bar'

Contrast this with v2.19.3:

$ go get github.com/urfave/cli/v2@v2.19
go: downgraded github.com/urfave/cli/v2 v2.27.1 => v2.19.3

$ go run main.go
NAME:
   boom - make an explosive entrance

USAGE:
   boom [global options] command [command options] [arguments...]

COMMANDS:
   foo      foo I say
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --help, -h  show help (default: false)


$ go run main.go  foo
foo! I say!
expecting 'foo', bot got FullName() '', HelpName ''

$ go run main.go  foo bar
bar! I say!
expecting 'foo bar', bot got FullName() 'foo bar', HelpName 'boom foo bar'

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".

  • Greg

@dearchap
Copy link
Contributor

@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.

@dearchap dearchap closed this as not planned Won't fix, can't repro, duplicate, stale Feb 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/v2 relates to / is being considered for v2 kind/bug describes or fixes a bug status/triage maintainers still need to look into this
Projects
None yet
Development

No branches or pull requests

2 participants