After installing new software, an already opened terminal with zsh won’t know about the new commands and cannot generate auto-complete for those. Apparently opening a new terminal fix the problem, but can the index (or whatever you call it) be rebuilt so that auto-complete will work on the old terminal?
I tried with compinit but that didn’t help. Also, is there a way that is not shell-dependent? It’s nice to have a way to verify the answer as well (except for uninstalling something and reinstalling it).
What I mean is after typing a few characters of a command’s name, I can press Tab, and zsh should do the rest to pull up the full name.
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
To rebuild the cache of executable commands, use rehash or hash -rf.
Make sure you haven’t unset the hash_list_all option (it causes even fewer disk accesses but makes the cache update less often).
If you don’t want to have to type a command, you can tell zsh not to trust its cache when completing by putting the following line in your ~/.zshrc¹:
zstyle ":completion:*:commands" rehash 1
There is a performance cost, but it is negligible on a typical desktop setting today. (It isn’t if you have $PATH on NFS, or a RAM-starved system.)
The zstyle command itself is documented in the zshmodule man page. The styles values are documented in the zshcompsys and zshcompwid man pages, or you can read the source (here, of the _command_names function). If you wanted some readable documentation… if you find some, let me know!
¹ requires zsh≥4.3.3, thanks Chris Johnsen
Method 2
If you are having problems getting “argument completion” working for the new commands then compinit is probably the command you need, however it has a caching mechanism that might be causing your problem.
The documentation for my version (4.3.10) says that compinit uses a cached “dump file”, .zcompdump, to store compiled completion functions to speed up subsequent invocations. It only invalidates the dump file when it notices a change in the number of completion files (fpath element files that start with #compdef … or #autoload …). Presumably installing new software would change the number of such completion files (assuming that it also installed its zsh auto-complete files in the right place), so I would expect a plain compinit to work. If you are in a situation where it does not work you may need to bypass or manually invalidate the dump file.
To skip using the dump file, use compinit -D; this will only affect the current shell.
To rebuild the dump file, remove it and rerun compinit:
rm -i ${ZDOTDIR:-${HOME:?No ZDOTDIR or HOME}}/.zcompdump &&
compinit
This will affect the current shell, existing shells that run plain compinit, and any future shells.
Method 3
I have found that when dealing with/developing completions that live in a file with a #compdef _foo foo that I need to use upon each edit:
unfunction _foo && compinit
in order to see the updated foo command completing with the updated changes.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0