cobra: Option to pass unknown flags to command

This is already built-in via a Unix “standard”. Typically, you append a double dash “–” and everything after that can get passed to a subcommand, another binary, etc rather than being parsed by the Cobra command as a flag.

For example:

my-cli command --normal-flag -- --this-is-ignored-by-cobra

I have a use case where I am writing a generic command runner. This runner is configurable by the user, and can call into many utility scripts, but the runner itself cannot know at build time what it will delegate to, only the user knows the flags at invocation time.

A binary plugin system where a driver is responsible for delegating to a subordinate cli is yet another use-case.

I see this kind of usage:

c := &cobra.Command{
	Use:		    "run",
	FParseErrWhitelist: cobra.FParseErrWhitelist{UnknownFlags: true},
	RunE: func(cmd *cobra.Command, args []string) error {
		cmd.SilenceUsage = true
		// use the hypothetical UnknownArgs() pflag API
		delegatedArgs := cmd.Flags().UnknownArgs()
		child := exec.Command(args[0], delegatedArgs...)
		return child.Run()
	},
}

I hadn’t noticed the reply here - sorry.

The bare “–” doesn’t work if the goal is to have a single interface where the end user doesn’t know what’s under the hood. It wouldn’t be obvious to the end user what is supposed follow the “–” at all in that case.

The desire is to provide a seamless experience by hanging natively or proxying help info/error into and flags.

On Thu, Apr 9, 2020, 00:05 github-actions[bot] notifications@github.com wrote:

This issue is being marked as stale due to a long period of inactivity

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/spf13/cobra/issues/739#issuecomment-611255329, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEOR3YESYXDOCZTDEJLKN3RLUGLFANCNFSM4FSSATVQ .

I agree this enhancement would be useful. For example, the helm binary currently has to have its own flag parser when it handles plugins. Helm doesn’t know about each different plugin’s flags so it cannot tell Cobra about them, but at the same time, helm has global flags that can be used with any plugins.

It would be nice for Cobra to parse the known global flags and hand over the unknown plugin flags.

Thanks for the feedback all! Yes, I think it makes sense to implement this. However, I think to have a streamlined, unified interface, the pflags library will need to include a flag set of unknown flags.

Looks like there’s already an open PR for this. Maybe we can generate some traction there: https://github.com/spf13/pflag/pull/199

Once we have a pflags unknown flag set, we should be able to easily get it back to the cobra application code.

This is a feature I would like to see too.

My use case is similar to the others stated: a wrapper for a set of 3rd party utilities. The possible flags/options/arguments cannot be known ahead of time. Converting usage from the other commands to my wrapper should be as seamless as possible. In some cases, it’ll just be replacing the executed command; in almost all other cases, it’ll be replacing the command and adding one flag.

My wrapper will have its own flags/options (and possibly config via Viper) that I’d like to be able to mix in with the other programs’ args flags and options. But any unknown flags/options should just be provided directly as entries in the args []string that is provided to the cobra command’s runner.

In the event my wrapper defines a flag that is meant for the other program, it makes sense to use -- to separate them, but it’d be annoying to always have to provide it. I want the replacement of the other programs with my wrapper to be as seamless and native as possible. But -- should rarely be needed, and definitely shouldn’t be required.

If anyone wants a workaround, I came up with this atrocity:

func extractUnknownArgs(flags *pflag.FlagSet, args []string) []string {
	unknownArgs := []string{}

	for i := 0; i < len(args); i++ {
		a := args[i]
		var f *pflag.Flag
		if a[0] == '-' {
			if a[1] == '-' {
				f = flags.Lookup(strings.SplitN(a[2:], "=", 2)[0])
			} else {
				for _, s := range a[1:] {
					f = flags.ShorthandLookup(string(s))
					if f == nil {
						break
					}
				}
			}
		}
		if f != nil {
			if f.NoOptDefVal == "" && i+1 < len(args) && f.Value.String() == args[i+1] {
				i++
			}
			continue
		}
		unknownArgs = append(unknownArgs, a)
	}
	return unknownArgs
}

@davidovich that’s essentially what i was hoping for. again, the -- workaround doesn’t work if what you are building is an interface to multiple other underlying things that you want to allow to handle the help/error info themselves.

i completely get that this isn’t the common cli use case, but it’s so close to doing what is needed to support better delegation that it’s frustrating to run into this when it happens.

I also think cobra could help here. Something in the lines of python’s parse_known_args would allow us to parse known flags and pass other flags to wrapped commands.

@marckhouzam apologies I might’ve formulated it a bit weird. What I meant is my CLI tool (https://github.com/Pluralith/pluralith-cli) runs Terraform under the hood and I would like to pass all unknown args my CLI gets on to terraform under the hood. Hope it makes more sense now

I’m honestly a bit dazzled that this isn’t supported out of the box. Took this for a no-brainer and was looking through the docs to find out how to pass some flags to Terraform under the hood. Never even considered this isn’t supported 👀

I’m assuming quite a few people feel the same way when they land here after searching for a while

@ghostsquad I think your particular scenario would fit well with the use of --: cli docker run alpine -- /bin/sh -c 'echo "hello"'

Once we have a pflags unknown flag set, we should be able to easily get it back to the cobra application code.

In fact, just a module version bump would suffice as Flags() returns a FlagSet already, on which we can call the new SetUnknownFlagsSlice() API.

Any movement on this? +1

@DanThePutzer to be precise, Terraform does not use Cobra (none of the Hashicorp CLI seem to). It does use spf13/pflag however, so you may be interested in the corresponding discussion https://github.com/spf13/pflag/pull/199

@davidovich fwiw, my fork has a disable help option, and has support for exposing unknowns, and it works with cobra (unit tests are run with my fork in place).

@mixe3y Unfortunately not, and the help is quite hardcoded currently. I have a need for this too, but haven’t come around to implementing that. As a workaround, I would probably scan os.Args and remove --help and -h before parsing with cobra, and then inject the --help to subcommand if if was found. But that does not remove the help from cobra as it insists on having a default help function.

@jharshman @wfernandes thoughts on adding some of this functionality? I’m hesitant since it’s baked into the posix standard with the --. And while yes, this may require application developers to include more documentation for their end users and include parsing the unknown args in their application code, I am not sure about subverting standards built into the operating system.

what you are building is an interface to multiple other underlying things …

I’m also hesitant since the general ethos for unix like commands is to do one thing really well and be enabled to chain in with other commands. For example, instead of a single “line by line” monolithic processor in unix that handles searching, replacing, and cut/pasting lines in files, we have grep, sed, and cut. These chain really well together but also work by themselves. This feels more in line with the spirit of cobra. I don’t believe cobra was ever intended to be a tool to generate large, multi-interface applications.

Would it be possible to break apart this monolithic CLI to better handle chaining and different interfaces?

However, I do see the benefit of implementing something like python’s parse_known_args. A single interface within cobra to abstract away some of this from the end users would help bring some more complete functionality.

@underrun can you give some examples of what an end user would experience with this “multiple other ulderlying” commands? Maybe I’m having a hard time picturing it.