long flags, that were accidentally using only one hyphen, are mistreated

[melksem]

When I use short and long names for a flag like this
removeCmd.PersistentFlags().StringVarP(&cfgNameParam, "name", "n", "", "name of configuration")
The flag is mistreated when I specify just one hyphen, but use the long name:

$ mycmd remove config -name wrong
Flag value: ame

So the extra characters are interpreted as the value instead of throwing an error. This is wrong imo.

[melksem]

Sorry for the late reply, busy times. As of now, I stick to just using long parameter names to overcome this issue. Am Sa., 21. Feb. 2026 um 21:54 Uhr schrieb darshjme-codes < ***@***.***>:

…

*darshjme-codes* left a comment (spf13/cobra#2358) <#2358 (comment)> This is a parsing ambiguity between short flag clusters and long flag names. Here's what's happening: *Current Behavior:* mycmd remove config -name wrong# Cobra interprets this as:# -n (short flag) with value "ame"# "wrong" as a positional argument *Why This Happens:* Cobra's flag parser checks for - prefix and then: 1. If next char is -, it's a long flag (--name) 2. If next char is not -, it's a short flag or flag cluster (-n, -abc) When you type -name: - Parser sees - followed by n - Treats it as short flag -n with value ame - The rest (wrong) becomes a positional arg *Expected Behavior:* Ideally, Cobra should detect that name doesn't match any short flag and throw an error: Error: unknown flag: -name Did you mean --name? *Similar Tools' Behavior:* - *GNU getopt:* Throws error for unknown short flags - *argparse (Python):* Shows "did you mean" suggestions - *Click (Python):* Strict mode rejects ambiguous flags *Potential Fix:* In Cobra's flag parsing logic, add validation: func (f *FlagSet) parseSingleShortFlag(arg string) error { if len(arg) > 2 { // e.g., -name (5 chars) // Check if this matches a long flag name longFlagName := arg[1:] // "name" if f.Lookup(longFlagName) != nil { return fmt.Errorf("flag '%s' requires double dash: --%s", arg, longFlagName) } } // ... existing short flag logic } *Workaround for Users:* Use strict flag parsing in your app: rootCmd.ParseFlags(os.Args[1:])rootCmd.Flags().SetInterspersed(false) // Strict flag ordering Or add custom validation: PreRunE: func(cmd *cobra.Command, args []string) error { for _, arg := range os.Args { if strings.HasPrefix(arg, "-") && !strings.HasPrefix(arg, "--") { if len(arg) > 2 && cmd.Flags().Lookup(arg[1:]) != nil { return fmt.Errorf("use --%s instead of %s", arg[1:], arg) } } } return nil } *Better Error Message:* Instead of silently accepting -name, show: Error: unknown flag: -n-a-m-e Did you mean: --name? *Testing Edge Cases:* - -name value (current bug) - -n=value (valid short flag with = assignment) - -nvalue (valid short flag with inline value) - -nabc (valid short flag cluster if n, a, b, c all exist) This is a real usability issue — developers often forget the second dash, and silent misinterpretation is worse than an error. Would you be open to a PR implementing stricter validation? — Reply to this email directly, view it on GitHub <#2358 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGUHPW3LCOXSUUNO7K4G66T4NDAZVAVCNFSM6AAAAACVWCEKU6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMZZGQ3DSMZTGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[willbeason]

The behavior of Cobra appears to align with the current glibc specification for getopt: https://sourceware.org/glibc/manual/2.43/html_node/Example-of-Getopt.html.

Specifically, since:

1. The flag has a short version, "-n"
2. The flag accepts string values

then the standard behavior for CLIs is to interpret "-name" as setting the "n" flag to the string "ame".