gopass: Command not found for zsh completion

This worked for me on mac os.

print -l $fpath | grep '.oh-my-zsh/completions'
mkdir ~/.oh-my-zsh/completions
gopass completion zsh > ~/.oh-my-zsh/completions/_gopass
rm ~/.zcompdump*

Naturally, I think I found the dynamic solution straight after I posted that. compdef _gopass gopass hooks it up. Resulting lines in .zshrc:

source <(gopass completion zsh | head -n -1 | tail -n +2)
compdef _gopass gopass

The head/tail drop the “broken” lines. I think the compdef should be added to the output of gopass completion zsh. If I use source <((gopass completion zsh | head -n -1 | tail -n +2); echo 'compdef _gopass gopass') to append the compdef to the output, this also works.

Actually, this is the wrong error, I’m getting something different in my host terminal.

bianca2% autoload -Uz compinit
compinit
bianca2% source <(gopass completion zsh)
_tags:comptags:36: can only be called from completion function
_tags:comptry:55: can only be called from completion function
_tags:comptags:60: can only be called from completion function
_tags:comptags:67: can only be called from completion function
_arguments:comparguments:319: can only be called from completion function
_arguments:comparguments:319: can only be called from completion function
_values:compvalues:11: can only be called from completion function

I don’t know the given distro/OS. But if the completion is not package properly the solution is gopass completion zsh > /usr/share/zsh/site-functions/_gopass.

Then you remove ~/.zcompdump and reload compinit.

In debian package file _gopass (probably generated from gopass completion zsh) should be placed to /usr/local/share/zsh/site-functions.

Current workaround for me:

gopass completion zsh | sudo tee /usr/local/share/zsh/site-functions/_gopass

The whole purpose of @Foxboron’s change, is that attempting to source the completion definition is a completely broken way to handle zsh completion and should not be done. zsh has an excellent completion system that works properly, as long as you actually use it.

Given that one of the major touted benefits of zsh is the completion system, any zsh installation that does not even use it is, well, broken.

The properly-written zsh completion for gopass is meant to be installed in the zsh completions directory, as defined by either the OS-level /usr/share/zsh/site-functions/, or the user-specified fpath. If gopass is installed via a package manager to usr/ then this should Just Work™, if it is installed to the user’s home directory in ~/bin or wherever, then the completion file should likewise be generated and stored in $fpath. The result is that zsh can automatically detect the completion, and load it when necessary, similar to how bash completions are stored in a global completions directory and automatically lazy-loaded when the command is tab-completed for the first time.

No user action or configuration in any way shape or form is required, other than making sure that the generic completion system is hooked up. This is, after all, far more convenient than requiring every single user-installed program to inject itself into the user’s shell rc files.

Again, this is the recommended and intended way that zsh completions are meant to be done. The fact that people were sourceing anything ever, was a bug that has been fixed.

This seems to work if I do gopass completion zsh > ~/newdir/_gopass.zsh and then add fpath=(~/newdir $fpath) to my .zshrc.

Reading some issues, I suspect the intention was that the completion would be a build artifact that ended up at /usr/lib/gopass/_gopass.zsh or something.

https://github.com/zsh-users/zsh-completions/blob/master/zsh-completions-howto.org might be worth reading, but I’m not certain.

I’m getting a similar, possibly related issue. If I press any key, then space (for completion), it prints something like this:

_tags:36: command not found: comptags
_tags:55: command not found: comptry
_tags:60: command not found: comptags
_tags:67: command not found: comptags
_tags:36: command not found: comptags
_tags:55: command not found: comptry
_tags:60: command not found: comptags
_tags:67: command not found: comptags
_tags:36: command not found: comptags
_tags:55: command not found: comptry
_tags:60: command not found: comptags
_tags:67: command not found: comptags
_tags:36: command not found: comptags
_tags:55: command not found: comptry
_tags:60: command not found: comptags
_tags:67: command not found: comptags
_tags:36: command not found: comptags
_tags:55: command not found: comptry
_tags:60: command not found: comptags
_tags:67: command not found: comptags
_tags:36: command not found: comptags
_tags:55: command not found: comptry
_tags:60: command not found: comptags
_tags:67: command not found: comptags

The biggest problem I can see coming with this, is the update process when using go get directly to update Gopass, since then if there are new commands or so, the zsh completion file must be manually updated. But then it must be done with write access to the completion folder…

Maybe the simplest way around it could be to instruct people to add this in their .zshrc:

fpath=( ${GOPATH}/src/github.com/justwatchcom/gopass/completions "${fpath[@]}" )

so it would add the folder completions in the Gopass repo as a way to provide completion and then you could have a Travis after_success callback so that the file gopass/completions/_gopass would be automatically created using gopass completion zsh when Travis succeeds.

However I do not know whether it is considered bad practice or not to tell people to add a folder to their fpath.

@ninrod Works for me so unsure, make sure all .zcompdump files are deleted. If it still doesn’t work it’s better to submit a bug to our tracker then using the upstream tracker.

Sourcing gopass completion zsh is the wrong approach to get zsh completions. The file needs to enter a compinit directory, and zsh will handle it. If there is documentation that is needed to resolve the confusion I’ll fix it.

Yes, the suggested changes will break the completion.