Quoted string starting with hyphen and space is interpreted as a flag (e.g. `"- h"`)

[GuySartorelli]

If a quoted string starts with a hyphen and a space, the character following the space is interpreted as a flag. For example some-command '- http' is interpreted as some-command -h and shows help information for the command.

If FParseErrWhitelist.UnknownFlags is set to false, an error is displayed which implies the space is being interpreted as a flag as well:

Error: unknown shorthand flag: ' ' in - h

I don't think whitespace is a valid flag name so this seems like a bug to me. It can likely be avoided with a simple condition in the flag parsing:

• For '- ', if unicode.IsSpace(rune(arg[1])), treat it as an argument
• For '-- ', if unicode.IsSpace(rune(arg[2])), treat it as an argument

See https://github.com/ddev/ddev/issues/7409 for additional context. Related issue: https://github.com/spf13/cobra/issues/1733

[Luap99]

As far as the application goes there is no such thing as a quoted string, an application gets a string array, the shell handles quotes and such. That means cobra see - http and it parses that as flag. Treating that as something else will likely be much more confusing and most likely causes compatibility issues in some form.

If you want to treat everything as argument the common way is to have -- as arg then all the following cli arguments are not being parsed as flags but are given as argument to your run function.

[GuySartorelli]

If you want to treat everything as argument

I don't want to treat everything as an argument, but I also don't want to have to start using -- for all of my arguments because sometimes arguments get treated as flags even when they're not.

Is it intended behaviour that - http is being treated as flags? Is it legitimate to have a space as a flag? If not, I recommend this be treated as a bug and be fixed in whatever updates are appropriate for breaking changes (assuming you follow semver).

Treating that as something else will likely be much more confusing and most likely causes compatibility issues in some form

I don't think that's the case? I don't think I've come across another CLI that treats spaces after a hyphen as flags nor ignores spaces after a hyphen and treats the next character as a flag.

Some throw an error, others treat the h as an argument and ignore the - but I haven't found one acting like cobra does.

[Luap99]

I don't think that's the case? I don't think I've come across another CLI that treats spaces after a hyphen as flags nor ignores spaces after a hyphen and treats the next character as a flag. Some throw an error, others treat the h as an argument and ignore the - but I haven't found one acting like cobra does.

All the command's I tried parse it as option and thus error as space is not a valid option for them.

$ cp "- a" a b
cp: invalid option -- ' '
Try 'cp --help' for more information.
$ cp "-a " a b
cp: invalid option -- ' '
Try 'cp --help' for more information.

cobra does not ignore the unkown flag by default you have set FParseErrWhitelist.UnknownFlags to true so that is why all flag parsing errors are getting ignored, you could have any other char that is not a valid flag it would still be ignored. If you don't want to ignore errors don't use that option? The reason the next char is treated as flag is because in the short form all short flags can be put after each other. cli -a -b is the same as cli -ab/ cli -ba and so on.

Is it intended behaviour that - http is being treated as flags? Is it legitimate to have a space as a flag? If not, I recommend this be treated as a bug and be fixed in whatever updates are appropriate for breaking changes (assuming you follow semver).

I am not a maintainer so I don't get to decide anything. I am just trying to explain that the current behavior seems to be consistent and special casing the space would likely make it less consistent. And regardless cobra does not parse flags to begin with, that is done by https://github.com/spf13/pflag