You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 27, 2022. It is now read-only.
There seems to be a problem with parsing both root- and sub-commands together.
I've put together this example which illustrates the in-ability to parse sub commands and their flags when a root flag is added. In this example, a GlobalConfiguration would be used to store the verbosity of logging under the -l or --loglevel flag. A subcomand, foo, is added which has is own FooConfiguration containing the flag --bar to be used solely by its processor and not necessarily elsewhere:
package main
import (
"fmt""os""github.com/containous/flaeg"
)
typeGlobalConfigurationstruct {
LogLevelstring`short:"l" long:"loglevel" description:"Output verbosity"`
}
typeFooConfigurationstruct {
Barstring`description:"Foo"`
}
varglobalConfig=&GlobalConfiguration{
LogLevel: "info",
}
varglobalPointersConfig=&GlobalConfiguration{}
varfooConfig=&FooConfiguration{
Bar: "bar",
}
varfooPointersConfig=&FooConfiguration{}
funcmain() {
rootCmd:=&flaeg.Command{
Name: "test",
Description: `Test flaeg sub-commands`,
Config: globalConfig,
DefaultPointersConfig: globalPointersConfig,
Run: func() error {
fmt.Println("I should have access to --loglevel but not --bar!")
fmt.Println("Loglevel: ", globalConfig.LogLevel)
fmt.Println("Bar: ", fooConfig.Bar)
returnnil
},
}
fooCmd:=&flaeg.Command{
Name: "foo",
Description: `Foo sub-command`,
Config: fooConfig,
DefaultPointersConfig: fooPointersConfig,
Run: func() error {
fmt.Println("I should have access to --loglevel and --bar!")
fmt.Println("Loglevel: ", globalConfig.LogLevel)
fmt.Println("Bar: ", fooConfig.Bar)
returnnil
},
}
// init flaegflaeg:=flaeg.New(rootCmd, os.Args[1:])
// add sub-command fooflaeg.AddCommand(fooCmd)
// run testiferr:=flaeg.Run(); err!=nil {
fmt.Println("Error %s", err.Error())
}
}
Under the normal assumption, and as per the declaration of usage, [flags] can be put aftere the command name, in this case test.
$ ./test -h
Test flaeg sub-commands
Usage: test [flags] <command> [<arguments>]
Use "test <command> --help"forhelp on any command.
Commands:
foo Foo sub-command
Flag's usage: test [--flag=flag_argument] [-f[flag_argument]] ... set flag_argument to flag(s) or: test [--flag[=true|false| ]] [-f[true|false| ]] ... set true/false to boolean flag(s)Flags:-l, --loglevel Output verbosity (default "info")-h, --help Print Help (this message) and exitError %s pflag: help requested
A subcommand, foo, is available and still makes these assumptions:
$ ./test foo -h
Foo sub-command
Usage: foo [flags] <command> [<arguments>]
Use "foo <command> --help"forhelp on any command.
Flag's usage: foo [--flag=flag_argument] [-f[flag_argument]] ... set flag_argument to flag(s) or: foo [--flag[=true|false| ]] [-f[true|false| ]] ... set true/false to boolean flag(s)Flags: --bar Foo (default "bar")-h, --help Print Help (this message) and exitError %s pflag: help requested
However, when adding "global", or root, flags to a sub-command call, we are immediately prompted with the inability to recognise the subcommand foo:
./test --loglevel=debug foo --bar=foo
Error here : unknown flag: --bar
Test flaeg sub-commands
Usage: test [flags] <command> [<arguments>]
Use "test <command> --help"forhelp on any command.
Commands:
foo Foo sub-command
Flag's usage: test [--flag=flag_argument] [-f[flag_argument]] ... set flag_argument to flag(s) or: test [--flag[=true|false| ]] [-f[true|false| ]] ... set true/false to boolean flag(s)Flags:-l, --loglevel Output verbosity (default "info")-h, --help Print Help (this message) and exitError %s unknown flag: --bar
Running the following yields the same result:
$ ./test --loglevel=debug --bar=foo foo
The text was updated successfully, but these errors were encountered:
This problem could largely be addressed in merging the GlobalConfigurationand FooConfiguration, but seeing as one seems to stem from the other, the assumption is that rootCmd options are available to sub-commands.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There seems to be a problem with parsing both root- and sub-commands together.
I've put together this example which illustrates the in-ability to parse sub commands and their flags when a root flag is added. In this example, a
GlobalConfiguration
would be used to store the verbosity of logging under the-l
or--loglevel
flag. A subcomand,foo
, is added which has is ownFooConfiguration
containing the flag--bar
to be used solely by its processor and not necessarily elsewhere:Under the normal assumption, and as per the declaration of usage,
[flags]
can be put aftere the command name, in this casetest
.A subcommand,
foo
, is available and still makes these assumptions:However, when adding "global", or root, flags to a sub-command call, we are immediately prompted with the inability to recognise the subcommand
foo
:Running the following yields the same result:
The text was updated successfully, but these errors were encountered: