zsh autocompletion generator

[anthonyfok]

There are desires among users (see gohugoio/hugo#1088) for an auto-completion generator for zsh, similar to what @eparis has made available for bash in his excellent work in #69.

So, here is a reminder so perhaps someone could use @eparis's excellent work for bash as the basis for the same for zsh. :-)

[c9s]

we did the zsh completion generator in PHP command line framework: https://github.com/c9s/CLIFramework#zsh-completion-with-lazy-completion-values

I think we can share some zsh functions for cobra :)
https://github.com/c9s/CLIFramework/tree/master/snippets/zsh

[anthonyfok]

Really wonderful, @c9s! And thank you for sharing! :-)

[matm]

Would love to have it. What's the status of that request?

[xh3b4sd]

I would love to see that happening. Who needs some candy to kick the tires?

[fxaguessy]

Zsh completion based on bash completion has been implemented in Kubernetes : https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/cmd/completion.go .
I integrated this code in another cobra-based project and its working fine.
We could perhaps integrate this code into cobra ?

[derimagia]

Ideally it wouldn't called bashcompinit. It's quite slow and zsh's autocomplete system can do a lot more than what can bash can do anyway. There any movement on this? If there's no movement I'd like to take a look.

[n10v]

Unfortunately, there is no progress. But every PR is welcome!

[kongslund]

@derimagia, did you start working on it?

[c9s]

I am working on it, but the code is not published yet

( my previous zsh completion generator was written in PHP, see https://github.com/c9s/CLIFramework )

[derimagia]

@kongslund I barely started yesterday, was planning to do it this weekend/week. @c9s let me know if there's anything you need for it.

[c9s]

@derimagia thanks!

I'm wondering if there is a gateway in cobra that zsh can ask the program to complete at the runtime, like CLIFramework use the PHP closure to return the dynamic result. for example, when completing arguments, the cli app send some http request and use the response for argument completion.

[derimagia]

https://github.com/spf13/cobra/blob/4673102358fdd630e3bb0eb6dee96e4b533d53ec/bash_completions.md

Look for "BashCompletionFunction"

Here's one for kubes: https://github.com/kubernetes/kubernetes/blob/0f3403d3510847a86fcbf43840409e4e79ba11bb/pkg/kubectl/cmd/cmd.go#L264

I would suggest doing 2 things here

1. Keep the current way of being able to call a function, adding one for ZSH but not recommending it
2. The recommended way would be to only pass the command to get the arguments and also the flags that can be used. Should have a way to autocomplete files too maybe, but I don't think we should be adding too much in this issue and instead improve it in the future by seeing how cli applications use it. We can then just make the dynamic complete functions for each language and merge in the static completions.

[derimagia]

Thinking about it a little more an alternative to providing the command to get the arguments, we could just add a method that accepts a POSIX function name and then we also provide some static functions for them to call as a simple api - (One to add arguments, one to add flags, one to add files, etc)

[n10v]

Please take a look at #497!

[0xdevalias]

Looks like some stuff has landed for implementing this already, but if more inspiration is needed, came across this that at least claims to have zsh support (haven't personally tried it yet): https://github.com/posener/complete

[eparis]

That sounds like a bug with boolSlice...

[babysnakes]

I see. Ok, I'll fix these two things later today and will try to look into bootSlice to see if I can understand what's going on...

[babysnakes]

Adopted the two suggested changes.

I'll appreciate if someone can try this on an app larger then couple of subcommands and flags.

Thanks.

[babysnakes]

@eparis (or someone else), I have one more question (sorry for spamming). I found a way to indicate optional arguments for flags. Should I use them always? how does cobra flags behaves if no argument is supplied?

[eparis]

@babysnakes I'm not sure what you mean. Any flag without a NoOptDefValue will use the next argument as a flag... If you have

cmd.Flags().StringVar(&sf1, "stringflag1")
cmd.Flags().StringVar(&sf2, "stringflag2")

and then you run

--stringflag1 --stringflag2

you will end up with

sf1="--stringflag2"
sf2=""

[babysnakes]

@eparis thanks.

I worked with many CLI options parsing systems and some of them allow for the options to be specified without argument. So in your example (--stringflag1 --stringflag2) it will end up specifying two flags. This happens with some libraries of dynamic languages that for example generate a hash with only the specified options so you can identify which were used with or without argument. In the way I'm currently doing zsh completion flag argument is either mandatory (and in this case will not complete the the --stringflag2 second flag in your example) or if I specify that no argument should be provided it can treat the argument to flag as command arg or subcommand.

I just wanted to ask for advice wether I should use the current enforcing way or use a way that allows optional arguments?

[rfay]

Wouldn't this whole conversation work better in a pull request?

[babysnakes]

@rfay in general you're right, however since I only tried it on a very small utility I wanted someone else to try it one a larger project before I submit a pull request. There is a gap between working in theory and in practice 😄 .

But I'll follow your advice, do some last fixes and submit a PR.

[eparis]

@babysnakes with pflag that's NoOptDefVal. If you set a NoOptDefVal on stringflag1 then the same arguments would parse differently.
https://github.com/spf13/pflag#setting-no-option-default-values-for-flags
describes it a bit...

var ip = flag.IntP("flagname", "f", 1234, "help message")

calling with

--flagname bob

Will cause a parse error.

var ip = flag.IntP("flagname", "f", 1234, "help message")
flag.Lookup("flagname").NoOptDefVal = "4321"

calling with

--flagname bob

will result in ip=4321 and args=[]string{"bob"}

Note however that flags with NoOptDefVal can still use the = for assignment. So

--flagname=2468

will result in ip=2468.

pflag is very specific about flags with an optional default and the parsing forms. No guessing or heuristics.

[babysnakes]

@eparis, I see. Thanks, I'll do some final checks and submit a pull request (asking for someone to test).

[babysnakes]

I added argument support for my zsh-completion PR, I would appreciate some input if someone cares to test it: #646.

[ericvn]

Hello,

I'm wondering what the current state of zsh completion is for cobra? So far, my testing seems to show what is currently in the latest release generates the file, but it doesn't work. There is a PR #828 which if I add on top of the current release does generate a file that works. I understand it's not a native solution but it seems that work has stalled. Getting #828 merged at least provides an interim solution.

[karuppiah7890]

@eparis Looking at the recent commits, I see that you are an active contributor and also the person who added bash completion. What are your thoughts on this issue? And based on your thoughts, we can all probably work towards closing this issue.

@ericvn I checked the PR. I have seen similar code in helm and used the same in a cli tool and it worked quite well, even though it looks like a interim solution

[ericvn]

I'm concerned that the current cobra Zsh completion file doesn't work anywhere, although there must be some subset that does to get by the initial commit. I see numerous CLIs like solo-io/gloo#654 where the cobra Zsh completion file fails to work. I did figure out how to make the current output file work by adding a small header and footer and indent the current output. This leaves the completion file a native Zsh completion file, but it is incomplete as it only supports nouns without any flag support.

I have created a commit against our CLI using code similar to #828 and it works as a solution.

[github-actions]

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

[marckhouzam]

With zsh completion now having feature parity with bash completion, we can probably close this issue?

/cc @jharshman @jpmcb

[ericvn]

At least as long as one is using a commit later than the last release (admittedly, I haven't tried with that commit yet).