proposal/need help: Command.ResetFlags() not reset its children command flags

[MakDon]

As mentioned in this issue, I am trying to use cobra as a command parser to parse the text sent to a bot, which means, a Command.ExecuteContext() would be called more than once.

And I found that in some cases ResetFlags() is not convenient enough to use. For example, assume we have code like this:

var RootCmd = &cobra.Command{
	Use:   "@chatops-bot [command]",
	Short: "a bot for ops",
}

var subCmd = &cobra.Command{
	Use:   "sub [command]",
	Short: "a sub command",
}

func init() {
	RootCmd.AddCommand(subCmd)
}

func main(){
        ret := &bytes.Buffer{}
	RootCmd.SetOut(ret)
	RootCmd.SetErr(ret)

	RootCmd.SetArgs([]string{"sub", "--help"}) // args is receive from the bot framwork
	RootCmd.ExecuteContext(context.Background())
}

After @chatops-bot sub --help is called, the sub command's help flag is set to true until i call sub.ResetFlags():

@chatops-bot sub doSomething // do it in the right way
@chatops-bot sub--help.            // show the help info
@chatops-bot sub doSomething // still show the help info

As for now, ResetFlags only reset the receiver command, but the children commands are still left there.

Is there a way to reset all the sub-commands' flags?
If there's not, could I make a PR that implements a method like Command.ResetFlagsRecursively()?

[github-actions[bot]]

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

[doujiang24]

I encountered the same situation and I workaround in this way: https://github.com/golang/debug/pull/8

And I don't think ResetFlagsRecursively suits this case. The current ResetFlags just delete the flags, not reset the flag value.

Maybe we can introduce the Command.ResetFlagValues and Command.ResetFlagValuesRecursively? So that we can fix https://github.com/golang/debug/pull/8 by using the Command.ResetFlagValuesRecursively.

[johnSchnake]

Seems like this would be helpful to me.

I haven't looked the details in a while so my only concern would be whether or not there could be complications due to custom, var backed flags and 'resetting' their default value. By that I mean that the default comes from the value of the variable in the first place, so if that had been modified/etc would we still be able to reset it as expected?

If we persisted that initial default value then I'm assuming it wouldn't be a problem.

[mcoops]

Agreed, think the idea of some sort of reset would be awesome.

Also appreciate the workaround posted by @doujiang24, just have to watch as it won't reset flags on StringSlice or StringArray but rather will just add the default to the end. Which kinda supports your concerns @johnSchnake

[ValarDragon]

Would appreciate ResetFlagValues being added, and some cloning of slices happening under the hood by default.

[rdnt]

My 2c: The solution present on golang/debug#8 does not work as consistently as I would have hoped. It works for direct subcommands but not for deeper levels.

The implementation from authzed/zed#188 on the other hand works for such cases, at least for my use-case (repeatedly calling the completion cmd or a custom cmd from the same root reference).