cobra icon indicating copy to clipboard operation
cobra copied to clipboard

flag value misparsed as subcommand

Open colin-arnott-xero opened this issue 2 years ago • 3 comments

it looks like the parser is having trouble with space delimited persistent flags, where a sub command aligns with the value of the first of many flags:

for ./app -z one -o one two: https://go.dev/play/p/cKaEuTEhWAZ wanted:

zero: one
one: one
args: []

got:

zero: -o
one: nil
args: [one two]

note: this does not trigger for the following cases

app -z two two          # only one flag
app -z=two -o=one two   # using equals delimited flags
app -z one -o two two   # colliding value is not first flag
app two -z two -one one # sub command comes first

colin-arnott-xero avatar Aug 18 '22 03:08 colin-arnott-xero

Interesting.

I can confirm this with kubectl (which uses cobra). In the example below, I try to run a pod in a namespace called "run", using the run command.

Fails:

$ kubectl -n run -v 1 run bar --image=nginx
Error from server (NotFound): namespaces "-v" not found

This works:

$ kubectl run -n run -v 1 bar --image=nginx
pod/bar created

brianpursley avatar Aug 19 '22 13:08 brianpursley

Another thing that is weird about this:

If you have multiple sub commands, the problem only occurs when the flag value matches the particular sub command you are running.

So for example, kubectl has a create sub command, but using -n create with the run sub command works fine:

$ kubectl -n create -v 1 run bar --image=nginx
pod/bar created

But if I use -n create with the create sub command, it fails:

$ kubectl -n create -v 1 create -f ~/foo.yaml
error: Unexpected args: [1 create]
See 'kubectl create -h' for help and examples

brianpursley avatar Aug 19 '22 13:08 brianpursley

I think I see what's causing this and it shouldn't be too complicated to fix. I will take a look at it and submit a PR with a fix.

brianpursley avatar Aug 19 '22 21:08 brianpursley

The Cobra project currently lacks enough contributors to adequately respond to all issues. This bot triages issues and PRs according to the following rules:

  • After 60d of inactivity, lifecycle/stale is applied. - After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied and the issue is closed. You can:
  • Make a comment to remove the stale label and show your support. The 60 days reset. - If an issue has lifecycle/rotten and is closed, comment and ask maintainers if they'd be interseted in reopening

github-actions[bot] avatar Nov 07 '22 00:11 github-actions[bot]

still broken

colin-arnott-xero avatar Nov 07 '22 00:11 colin-arnott-xero