Shell completion does not support the "no space" format of short flags

[marckhouzam]

Cobra supports a "no space" format for short flags. I had used it before, but I never really paid attention to it in the code base. For example:

kubectl -ninfra-prometheus get cm

Notice the lack of a space between the -n flag and the infra-prometheus namespace name.
In fact, this seems to work when using multiple short flags:

kubectl exec -itninfra-prometheus prom2-prometheus-server-58f7858467-wlqkg -- sh

Notice how the -i, -t and -n short flags are used together, with only the last one requiring an argument, and that that argument does not need to be preceded by a space.

Granted that the second example seems unlikely to be used, however the first example seems reasonable (in fact I used it a lot in the past).

Shell completion does not support those "no space" scenarios:

kubectl -ninfra-pro<TAB>
# Nothing suggested

I haven't had time to investigate, but I wanted to at least document the issue.

[Luap99]

I agree that this would be great. At the moment we reverse engineer the flag parsing code which leads to problems like this.
I think it would help if we somehow combine the parsing code and shell completion to keep it more consistent.

[marckhouzam]

I agree that this would be great. At the moment we reverse engineer the flag parsing code which leads to problems like this. I think it would help if we somehow combine the parsing code and shell completion to keep it more consistent.

Agreed. I was thinking that maybe we can use pflags directly to do the flag parsing. There may be options available in pflag that handle the special cases that completion requires. But I'll have to look into the details of pflag to see what we can do.

[github-actions]

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

[marckhouzam]

Still valid.

[mazitovt]

Should kubectl -n<TAB> and kubectl -itn<TAB> complete to all available namespaces or complete to flag -n?

[github-actions]

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

[marckhouzam]

Should kubectl -n<TAB> and kubectl -itn<TAB> complete to all available namespaces or complete to flag -n?

To all available namespaces

[marckhouzam]

Should kubectl -n<TAB> and kubectl -itn<TAB> complete to all available namespaces or complete to flag -n?

To all available namespaces

Actually, probably not. Currently if we do kubectl -n<TAB>, the completion will insert a space and then let the user input or complete the flag value. So we could do the same for kubectl -itn<TAB> (the completion will need to be -itn for it to match what is on the command-line).

But if we have kubectl -itnm<TAB> then the completion should start completing namespace names (but it will still need to prefix them with -itnm in this example)

Does that make sense?