ZSHCOMPCTL(1)

πŸ’… ZSHCOMPCTL(1) β€” bestie edition πŸŽ€

ok so this is zshcompctl, from the General Commands Manual β€” the whole ZSHCOMPCTL(1) situation. grab a strawberry drink πŸ“ and let's get into it.

✨ NAME ✨

zshcompctl β€” zsh programmable completion. that's it, that's the name, she's iconic πŸ‘‘

🌸 DESCRIPTION 🌸

so your fave shell has two ways of doing word completion on the command line. no cap. if you're new to zsh you might lowkey prefer the newer, way more powerful system built on shell functions β€” that one's documented in zshcompsys(1), and the basic shell mechanisms holding it up live in zshcompwid(1). πŸ¦‹

but this manual entry? this one is all about the older compctl command. vintage. retro. still slaying.

compctl [ -CDT ] options [ command ... ]
compctl [ -CDT ] options [ -x pattern options - ... -- ]
        [ + options [ -x ... -- ] ... [+] ] [ command ... ]
compctl -M match-specs ...
compctl -L [ -CDTM ] [ command ... ]
compctl + command ...

so what does it do? it controls the editor's completion behavior according to whatever set of options you hand it. πŸ’« various editing commands β€” notably expand-or-complete-word, which is usually bound to tab β€” will attempt to complete a word you typed. other ones, notably delete-char-or-list, usually bound to ^D in EMACS editing mode, will list out the possibilities. and compctl is the one deciding what those possibilities are. main character energy fr fr.

like, they could be filenames (the most common case, and hence the default β€” she's the standard for a reason), shell variables, or words from a list you specified yourself. you choose. πŸ’…


πŸ‘‘ COMMAND FLAGS πŸ‘‘

completion of a command's arguments can be different for each command, or it can just use the default. and the behavior when completing the command word itself can also be specified separately. these all correspond to the following flags and arguments β€” and all of them (except for -L) may be combined with any combination of the options described later in the Option Flags section. bestie combo meal πŸ“

  • command ... β€” controls completion for the named commands, which must be listed last on the command line. if completion is attempted for a command with a pathname containing slashes and no completion definition is found, the search gets retried with the last pathname component. and if the command starts with a =, completion is tried with the pathname of the command. 🧚

any of the command strings may be patterns of the form normally used for filename generation. quote them so they don't get immediately expanded bestie β€” for example the command string 'foo*' arranges for completion of the words of any command beginning with foo. when completion is attempted, all pattern completions are tried in the reverse order of their definition until one matches. by default, completion then proceeds as normal, i.e. the shell will try to generate more matches for the specific command on the command line; you can override that by including -tn in the flags for the pattern completion. πŸ”₯

ngl, important: aliases are expanded before the command name is determined, unless the COMPLETE_ALIASES option is set. and commands may not be combined with the -C, -D or -T flags. πŸ’€
  • -C β€” controls completion when the command word itself is being completed. if no compctl -C command has been issued, the names of any executable command get completed (whether in the path or specific to the shell, like aliases or functions). ✨
  • -D β€” controls default completion behavior for the arguments of commands that haven't been assigned any special behavior. if no compctl -D command has been issued, filenames are completed. the humble default, we love her 🫢
  • -T β€” supplies completion flags to be used before any other processing is done, even before processing for compctls defined for specific commands. this is especially useful when combined with extended completion (the -x flag, see the Extended Completion section below). using this flag you can define default behavior that applies to all commands without exception, or alter the standard behavior for all commands. πŸ‘‘

for example β€” if your access to the user database is too slow and/or it contains too many users (so completing after ~ is too slow to be usable 😭), you can use:

compctl -T -x 's[~] C[0,[^/]#]' -k friends -S/ -tn

to complete the strings in the array friends after a ~. the C[...] argument is necessary so that this form of ~-completion isn't tried after the directory name is finished. don't skip it, iykyk πŸ’…

  • -L β€” lists the existing completion behavior in a manner suitable for putting into a start-up script; the existing behavior is not changed. any combination of the above forms, or the -M flag (which must follow the -L flag), may be specified β€” otherwise all defined completions are listed. any other flags you supply are just ignored. rude but ok πŸ™ˆ
  • no argument β€” if no argument is given, compctl lists all defined completions in an abbreviated form; with a list of options, all completions with those flags set (not counting extended completion) are listed. πŸ¦‹

if the + flag is alone and followed immediately by the command list, the completion behavior for all the commands in that list gets reset to the default. in other words, completion will subsequently use the options specified by the -D flag. factory reset, but make it fashion ✨

the form with -M as the first and only option defines global matching specifications (see zshcompwid). the match specifications given will be used for every completion attempt (only when using compctl, not with the new completion system) and are tried in the order in which they're defined until one generates at least one match. e.g.: 🌈

compctl -M '' 'm:{a-zA-Z}={A-Za-z}'

this will first try completion without any global match specifications (the empty string) and, if that generates no matches, will try case insensitive completion. adaptive queen πŸ’œ


πŸŽ€ OPTION FLAGS πŸŽ€

[ -fcFBdeaRGovNAIOPZEnbjrzu/12 ]
[ -k array ] [ -g globstring ] [ -s subststring ]
[ -K function ]
[ -Q ] [ -P prefix ] [ -S suffix ]
[ -W file-prefix ] [ -H num pattern ]
[ -q ] [ -X explanation ] [ -Y explanation ]
[ -y func-or-var ] [ -l cmd ] [ -h cmd ] [ -U ]
[ -t continue ] [ -J name ] [ -V name ]
[ -M match-spec ]

the remaining options specify the type of command arguments to look for during completion. any combination of these flags may be specified; the result is a sorted list of all the possibilities. literally a sorted list. she's organized. πŸ’… the options are as follows:

🌸 Simple Flags 🌸

these produce completion lists made up by the shell itself:

  • -f β€” filenames and file system paths. the classic πŸŽ€
  • -/ β€” just file system paths.
  • -c β€” command names, including aliases, shell functions, builtins and reserved words. the whole friend group πŸ’–
  • -F β€” function names.
  • -B β€” names of builtin commands.
  • -m β€” names of external commands.
  • -w β€” reserved words.
  • -a β€” alias names.
  • -R β€” names of regular (non-global) aliases.
  • -G β€” names of global aliases.
  • -d β€” this can be combined with -F, -B, -w, -a, -R and -G to get names of disabled functions, builtins, reserved words or aliases. the ones on a break 😴
  • -e β€” this option (to show enabled commands) is in effect by default, but may be combined with -d; -de in combination with -F, -B, -w, -a, -R and -G will complete names of functions, builtins, reserved words or aliases whether or not they are disabled. everyone's invited 🫢
  • -o β€” names of shell options (see zshoptions(1)).
  • -v β€” names of any variable defined in the shell.
  • -N β€” names of scalar (non-array) parameters.
  • -A β€” array names.
  • -I β€” names of integer variables.
  • -O β€” names of read-only variables. no touchy πŸ™ˆ
  • -p β€” names of parameters used by the shell (including special parameters).
  • -Z β€” names of shell special parameters.
  • -E β€” names of environment variables.
  • -n β€” named directories.
  • -b β€” key binding names.
  • -j β€” job names: the first word of the job leader's command line. this one's useful with the kill builtin. πŸ’€
  • -r β€” names of running jobs.
  • -z β€” names of suspended jobs.
  • -u β€” user names.

πŸ¦‹ Flags with Arguments πŸ¦‹

these have user-supplied arguments to determine how the completion list gets made up:

  • -k array β€” names taken from the elements of $array (note that the $ does not appear on the command line). alternatively, the argument array itself may be a set of space- or comma-separated values in parentheses, in which any delimiter may be escaped with a backslash; in that case the argument should be quoted. for example:
compctl -k "(cputime filesize datasize stacksize
            coredumpsize resident descriptors)" limit
  • -g globstring β€” the globstring is expanded using filename globbing; it should be quoted to protect it from immediate expansion. the resulting filenames are taken as the possible completions. use *(/) instead of */ for directories. the fignore special parameter is not applied to the resulting files. more than one pattern may be given separated by blanks. (note that brace expansion is not part of globbing β€” use the syntax (either|or) to match alternatives.) 🧚
  • -s subststring β€” the subststring is split into words and these words are then expanded using all shell expansion mechanisms (see zshexpn(1)). the resulting words are taken as possible completions. the fignore special parameter is not applied to the resulting files. note that -g is faster for filenames. speed matters bestie ⭐
  • -K function β€” call the given function to get the completions. unless the name starts with an underscore, the function is passed two arguments: the prefix and the suffix of the word on which completion is to be attempted β€” in other words those characters before the cursor position, and those from the cursor position onwards. the whole command line can be accessed with the -c and -l flags of the read builtin. the function should set the variable reply to an array containing the completions (one completion per element); note that reply should not be made local to the function. from such a function the command line can be accessed with the -c and -l flags to the read builtin. for example: πŸ’–
function whoson { reply=(`users`); }
compctl -K whoson talk

completes only logged-on users after talk. note that whoson must return an array, so reply=users`` would be incorrect. πŸ’€

  • -H num pattern β€” the possible completions are taken from the last num history lines. only words matching pattern are taken. if num is zero or negative the whole history is searched, and if pattern is the empty string all words are taken (as with *). a typical use is:
compctl -D -f + -H 0 ''

🌸 (part 1 of 3 β€” the vibe continues, keep reading)

which forces completion to look back in the history list for a word if no filename matches.

(yeah β€” no filename match? it goes rummaging through your history list for a word instead. resourceful queen behavior πŸ’…)

πŸŽ€ Control Flags πŸŽ€

okay so these are the backstage crew 🧚 β€” they do not directly say what kinds of name to complete, they just manipulate the options that do. Support acts, not main characters.

  • -Q β€” tells the shell not to quote any metacharacters in the possible completions. Normally the results of a completion get inserted into the command line with any metacharacters quoted so they're interpreted as normal characters β€” which is exactly correct for filenames and ordinary strings. But for special effects, like inserting a backquoted expression from a completion array (-k) so that the expression won't be evaluated until the complete line is executed, you have to use this option. no cap πŸ”₯
  • -P prefix β€” the prefix gets inserted just before the completed string. Anything you already typed as an initial part still gets completed, and the whole prefix is ignored for completion purposes. Like:
compctl -j -P "%" kill

which inserts a % after the kill command and then completes job names. iconic little garnish ✨

  • -S suffix β€” when a completion is found, the suffix gets inserted after the completed string. In the case of menu completion the suffix goes in immediately, but you can still cycle through the list of completions by repeatedly hitting the same key. πŸŽ€
  • -W file-prefix β€” with directory file-prefix: for command, file, directory and globbing completion (options -c, -f, -/, -g), the file prefix is implicitly added in front of the completion. Example time:
compctl -/ -W ~/Mail maildirs

completes any subdirectories to any depth beneath the directory ~/Mail, even though that prefix does not appear on the command line. Sneaky. The file-prefix may also be of the form accepted by the -k flag, i.e. the name of an array or a literal list in parenthesis. In that case all the directories in the list will be searched for possible completions. πŸ’œ

  • -q β€” if used with a suffix as specified by the -S option, this causes the suffix to be removed if the next character typed is a blank or does not insert anything, or if the suffix consists of only one character and the next character typed is the same character. This is the same rule used for the AUTO_REMOVE_SLASH option. Most useful for list separators (comma, colon, etc.). clean-up crew fr 🧹
  • -l cmd β€” restricts the range of command line words that are considered to be arguments. If you combine it with one of the extended completion patterns p[...], r[...], or R[...] (see the section Extended Completion below), the range gets restricted to the range of arguments specified in the brackets. Completion is then performed as if those had been given as arguments to the cmd supplied with the option. If the cmd string is empty, the first word in the range is instead taken as the command name, and command name completion is performed on the first word in the range. For example:
compctl -x 'r[-exec,;]' -l '' -- find

completes arguments between -exec and the following ; (or the end of the command line if there is no such string) as if they were a separate command line. it's giving sub-command-line 😭

  • -h cmd β€” normally zsh completes quoted strings as a whole. With this option, completion can be done separately on different parts of such strings. It works like the -l option but makes the completion code work on the parts of the current word that are separated by spaces. These parts are completed as if they were arguments to the given cmd. If cmd is the empty string, the first part is completed as a command name, as with -l. πŸ¦‹
  • -U β€” use the whole list of possible completions, whether or not they actually match the word on the command line. The word typed so far will be deleted. Most useful with a function (given by the -K option) which can examine the word components passed to it (or via the read builtin's -c and -l flags) and use its own criteria to decide what matches. If there is no completion, the original word is retained. And since the produced possible completions seldom have interesting common prefixes and suffixes, menu completion is started immediately if AUTO_MENU is set and this flag is used. ⚑
  • -y func-or-var β€” the list provided by func-or-var is displayed instead of the list of completions whenever a listing is required; the actual completions to be inserted are not affected. It can be provided in two ways. First: if func-or-var begins with a $ it defines a variable, or if it begins with a left parenthesis a literal array, which contains the list. A variable may have been set by a call to a function using the -K option. Otherwise it contains the name of a function which will be executed to create the list. That function gets passed, as an argument list, all matching completions β€” including prefixes and suffixes expanded in full β€” and should set the array reply to the result. In both cases, the display list is only retrieved after a complete list of matches has been created. πŸ“
heads up bestie: the returned list does not have to correspond β€” even in length β€” to the original set of matches, and may be passed as a scalar instead of an array. No special formatting of characters is performed on the output in this case; in particular, newlines are printed literally and if they appear, output in columns is suppressed. 🫢
  • -X explanation β€” print explanation when trying completion on the current set of options. A %n in this string is replaced by the number of matches that were added for this explanation string. The explanation only appears if completion was tried and there was no unique match, or when listing completions. Explanation strings get listed together with the matches of the group specified together with the -X option (using the -J or -V option). If the same explanation string is given to multiple -X options, the string appears only once (for each group) and the number of matches shown for the %n is the total number of all matches for each of these uses. In any case, the explanation string will only be shown if there was at least one match added for the explanation string.

And the flair ✨: the sequences %B, %b, %S, %s, %U, and %u specify output attributes (bold, standout, and underline), %F, %f, %K, %k specify foreground and background colours, and %{...%} can be used to include literal escape sequences as in prompts. πŸ’…

  • -Y explanation β€” identical to -X, except that the explanation first undergoes expansion following the usual rules for strings in double quotes. The expansion is carried out after any functions are called for the -K or -y options, allowing them to set variables. πŸ”₯
  • -t continue β€” the continue-string contains a character that specifies which set of completion flags should be used next. It's useful:

(i) With -T, or when trying a list of pattern completions, when compctl would usually continue with ordinary processing after finding matches; this can be suppressed with -tn.

(ii) With a list of alternatives separated by +, when compctl would normally stop when one of the alternatives generates matches. It can be forced to consider the next set of completions by adding -t+ to the flags of the alternative before the +.

(iii) In an extended completion list (see below), when compctl would normally continue until a set of conditions succeeded, then use only the immediately following flags. With -t-, compctl will continue trying extended completions after the next -; with -tx it will attempt completion with the default flags, in other words those before the -x.

  • -J name β€” this gives the name of the group the matches should be placed in. Groups are listed and sorted separately; likewise, menu completion will offer the matches in the groups in the order in which the groups were defined. If no group name is explicitly given, the matches are stored in a group named default. The first time a group name is encountered, a group with that name is created. After that, all matches with the same group name are stored in that group. 🌈

This can be useful with non-exclusive alternative completions. For example, in

compctl -f -J files -t+ + -v -J variables foo

both files and variables are possible completions, since the -t+ forces both sets of alternatives before and after the + to be considered at once. Because of the -J options, though, all files are listed before all variables. organization queen πŸ‘‘

  • -V name β€” like -J, but matches within the group will not be sorted in listings nor in menu completion. These unsorted groups are in a different name space from the sorted ones, so groups defined as -J files and -V files are distinct. ⭐
  • -1 β€” if given together with the -V option, makes only consecutive duplicates in the group be removed. Note that groups with and without this flag are in different name spaces. πŸ™ˆ
  • -2 β€” if given together with the -J or -V option, makes all duplicates be kept. Again, groups with and without this flag are in different name spaces. πŸ’€
  • -M match-spec β€” this defines additional matching control specifications that should be used only when testing words for the list of flags this flag appears in. The format of the match-spec string is described in zshcompwid. πŸ”

🌈 ALTERNATIVE COMPLETION 🌈

compctl [ -CDT ] options + options [ + ... ] [ + ] command ...

The form with + specifies alternative options. Completion is tried with the options before the first +. If that produces no matches, completion is tried with the flags after the +, and so on. If there are no flags after the last + and a match hasn't been found up to that point, default completion is tried. And if the list of flags contains a -t with a + character, the next list of flags is used even if the current list produced matches. no cap, it just moves on 😀

Additional options are available that restrict completion to some part of the command line; this is referred to as extended completion. more on that later bestie πŸ’–

✨ EXTENDED COMPLETION ✨

Okay bestie, this is the fancy part β€” the whole vibe where you get to say "if the user typed this, do that; otherwise do the other thing." Two shapes of it exist:

compctl [ -CDT ] options -x pattern options - ... --
        [ command ... ]
compctl [ -CDT ] options [ -x pattern options - ... -- ]
        [ + options [ -x ... -- ] ... [+] ] [ command ... ]

The form with -x gives you extended completion for the commands you list, and β€” as you can see up there β€” you can totally combo it with alternative completion using +. πŸ’…

So here's how it goes down: each pattern gets checked in turn, one at a time, in order. The second one of them matches, boom, the options that follow it (the ones described back in the Option Flags section, same rules, no new lore) get used to generate the possible completions. And if literally none of the patterns match? Then the options you gave before the -x are the ones in charge. Simple as. ✨

Heads up, bestie: each pattern has to be handed over as a single argument, and please please please quote it so the shell doesn't go expanding your metacharacters before compctl ever sees them. πŸ™ˆ

πŸŽ€ How a pattern is built πŸŽ€

A pattern is made of sub-patterns glued together with commas, and it matches if at least one of those comma sub-patterns matches β€” they're or'ed, basically the group chat voting "any of us is fine." Those sub-patterns are in turn built from other sub-patterns separated by white spaces, and those match only if all of them match β€” they're and'ed, ride-or-die, all-for-one. 🫢

An element of the sub-patterns looks like this: c[...][...], where those bracket pairs can repeat as many times as you need, and it matches if any of the bracket sets match β€” another little or party. The example down below makes all of this way clearer, promise. 🌸

The elements can be any of the following, and yeah, this is the whole menu:

  • s[string]... β€” matches if the current word on the command line starts with one of the strings in the brackets. Key detail: the string is not removed and is not part of the completion. πŸ“
  • S[string]... β€” same energy as s[string], except this time the string is part of the completion. Iconic difference, honestly.
  • p[from,to]... β€” matches if the number of the current word lands between one of the from/to pairs, inclusive. The comma and the to are optional; to just defaults to whatever from is. And the numbers can be negative β€” -n means the n'th-last word on the line. πŸ’œ
  • c[offset,string]... β€” matches if the string matches the word offset by offset from the current word position. Usually you'll want offset negative, ngl.
  • C[offset,pattern]... β€” like c, but it's doing pattern matching instead.
  • w[index,string]... β€” matches if the word in position index is equal to the corresponding string. Sneaky detail: the word count happens after any alias expansion. πŸ‘€
  • W[index,pattern]... β€” like w, but with pattern matching instead.
  • n[index,string]... β€” matches if the current word contains string. Everything up to and including the indexth occurrence of that string gets left out of the completion β€” but the rest counts. index can be negative to count from the end; most of the time you'll see index as 1 or -1. For example:
compctl -s '`users`' -x 'n[1,@]' -k hosts -- talk

That one will usually complete usernames, but the moment you drop an @ after the name, it completes from the array hosts instead (assumed to hold hostnames β€” you gotta build that array yourself, babe, it's not gonna manifest). And other commands like rcp can be handled the same cute way. 😭

  • N[index,string]... β€” like n, except the string is treated as a character class. Anything up to and including the indexth occurrence of any of the characters in that string is out of the completion. ✨
  • m[min,max]... β€” matches if the total number of words sits between min and max, inclusive.
  • r[str1,str2]... β€” matches if the cursor is after a word with prefix str1. If there's also a word with prefix str2 on the command line after the one str1 matched, then it only matches if the cursor is before that word. Omit the comma and str2 and it just matches when the cursor is after a word with prefix str1. πŸ¦‹
  • R[str1,str2]... β€” like r, but pattern matching instead.
  • q[str]... β€” matches when the word currently being completed is sitting in single quotes and str begins with the letter s; or when completion is happening inside double quotes and str starts with the letter d; or when completion is in backticks and str starts with a b. Three-for-one, we love a multitasker. πŸ‘‘

🌈 EXAMPLE 🌈

Here's the moment you've all been waiting for, the demo:

compctl -u -x 's[+] c[-1,-f],s[-f+]' \
  -g '~/Mail/*(:t)' - 's[-f],c[-1,-f]' -f -- mail

And this is absolutely to be read like the world's most extra flowchart. If the current command is mail, then:

  • if ((the current word begins with + and the previous word is -f) or (the current word begins with -f+)), then complete the non-directory part (you know, the :t glob modifier) of files in the directory ~/Mail; else
  • if the current word begins with -f or the previous word was -f, then complete any file; else
  • complete user names. πŸŽ€

Periodt. That's the whole cascade. 🫢


And that's a wrap, bestie! πŸ’– This little masterpiece is from zsh 5.9.2, dated July 12, 2026 β€” go forth and complete things iconically. πŸ‘‘βœ¨

πŸ“¦ where this page comes from