It often happens to me that bash disables auto completion for certain commands. This forces me to add random symbol to name of command, use autocompletion, and than fix the command name. This is rather annoying. For example:

# I type:
openvpn s<tab>
# Nothing happens, so I add x
openvpnx s<tab>
# Now this expands to
openvpnx somepath

# Same with ./configure or many other commands...

Is there a way to disable the disabling so that auto-completion ALWAYS works?

  • Are you saying that "openvpn" is not the right command; that "openvpnx" is the right command, and you're expecting what? Bash to complete "openvpn" after you've typed "s [TAB]"? Should you hit tab after "openvpn" so that it can complete that to "openvpnx"?
    – Jeff Schaller
    Mar 7, 2017 at 18:51
  • No, I am trying to say that when I use the right command "openvpn" then autocompletion for path stops working, I have to cripple the command name to get it working, then I have to fix the name back
    – Petr
    Mar 8, 2017 at 10:00
  • 1
    I am having the same problem with openvpn. There seems to be no active openvpn completion scripts for openvpn, but normal file completion is disabled. If I do complete -p openvpn, I get bash: complete: openvpn: no completion specification. But pressing TAB after typing openvpn does nothing. If I do complete -r to delete all completion and then try to press TAB after typing openvpn I do get normal file based completion. The no completion specification is measleading. As it the returns the same error for non existing command, for example, if I do complete -p nonexistent. Jul 9, 2019 at 11:07
  • My answer is not a "new question". I am saying bash_completion needs a systematic rework. How can you expect some interesting Qs being answered by one clear answer? The Q is not fully answered. I agree with the original Q, I agree with the given answers. But the Q is NOT amswered, and you are not helping, just ruling.
    – user359065
    Jul 9, 2019 at 14:07
  • I completely rewrote my answer. Can it be "reopened". It's all soaked in an alarming pink.
    – user359065
    Jul 9, 2019 at 17:25

4 Answers 4


Listing completions

You can see what Bash/Readline uses for completing a command using complete -p command, e.g., if I run complete -p openvpn, I get

bash: complete: openvpn: no completion specification

This shows that Readline used by my shell doesn’t have any specific completion for the openvpn command so it defaults to the traditional form of completion, i.e., filenames.

Another example (to demonstrate a defined completion):

$ complete -p dillo
complete -F _filedir_xspec dillo

This indicates that a function named _filedir_xspec is used to provide completions for the dillo command.

Removing completions

To remove a defined completion, use the -r option with the complete builtin:

complete -r openvpn
  • Hello but how to add the autocompletion for openvpn ?
    – Topsy
    Jul 7, 2019 at 3:14
  • Note that bash seems to load completion functions lazily and complete -p <COMMAND> may not work until completion has been invoked for COMMAND.
    – user84207
    Jul 22, 2019 at 5:13

Bash has programmable completion. Since 1999, it has been capable of adapting the completion of command arguments to the command, and not just completing file names. File names are the default when no command-specific completion has been configured (that's why you're getting file names when you change the command to openvpnx).

Programmable completion is normally activated by loading /etc/bash_completion. If you don't want programmable completion at all, and always want to complete file names even in contexts where file names don't make sense, remove this from your .bashrc.

It appears that you have custom completion for arguments to the openvpn command, and that this completion code doesn't offer anything for the first argument. I don't know why that is, it might be a bug in the completion code. Useful completion code would complete options and their arguments. Run complete -p openvpn to see what code is invoked to complete arguments for openvpn. You can disable this custom completion code with complete -r openvpn, but then you'd be back to file names only, which is useful on the command line of openvpn only after a few options.

Regardless of completion settings, you can always complete a file name by invoking complete-filename (default binding: M-/) instead of complete (TAB).

  • 1
    Hm, but I am getting "bash: complete: ./configure: no completion specification" for ./configure, yet it doesn't allow me to autocomplete file path
    – Petr
    Mar 8, 2017 at 10:03
  • @Petr That's because the completion specification is for configure, not for ./configure. It takes the base name of the command into account, not the full path. Mar 8, 2017 at 11:04
  • "If you don't want programmable completion at all, and always want to complete file names even in contexts where file names don't make sense, remove this from your .bashrc". In current versions of Debian/Ubuntu, bash_completion is loaded by default via /etc/profile => /etc/profile.d/bash_completion.sh => /usr/share/bash-completion/bash_completion, so opting-out without editing system files is not particularly straightforward.
    – jamesdlin
    Apr 25, 2021 at 0:33
  • @jamesdlin Well, one way is to put exec bash in your .bash_profile, so you never run an interactive login shell. At least on Ubuntu 20.04, it's only /etc/profile that includes bash_completion.sh, it's commented out in /etc/bash.bashrc. (All of which makes zero sense, but the system bashrc/profile has been broken since forever on Debian.) And if your distribution forces /etc/bash_completion in system files, running complete -r disables all the fancy rules for commands, or shopt -u progcomp disables programmable completion. Apr 25, 2021 at 11:29

The first problem is that the openvpn binary name matches its entry in init.d directory.

complete | grep -i openvpn


complete -F _service /etc/init.d/openvpn

On Ubuntu and derivatives this comes from the code in /usr/share/bash-completion/bash_completion (part of bash-completion package).

for svcdir in ${sysvdirs[@]}; do
    for svc in $svcdir/!($_backup_glob); do
        [[ -x $svc ]] && complete -F _service $svc

Comment out this block. Restart your instance of bash. Try to do autocomplete openvpn with TAB and do

complete | grep -i openvpn

That produces

complete -F _openvpn /etc/init.d/openvpn

The second problem comes from /usr/share/bash-completion/completions/openvpn. It tries to autocomplete .conf files from /etc/openvpn and is an obstacle if you try to run openvpn with some ad-hoc config file lying outside of /etc/openvpn.

Just delete it and restart your instance of bash.

sudo rm /usr/share/bash-completion/completions/openvpn

Now you should get standard file completion for openvpn command with TAB key.

If you run

complete -p | grep openvpn

after you have tried to autocomplete after openvpn, you should now get

complete -F _minimal openvpn`

A better approach would have been to fix/extend bash-completion scripts for openvpn. But this a story for another day.

If you later want to go back to pristine condition of bash-completion package just reinstall it with the following command.

apt-get install --reinstall bash-completion

The sad part of my answer is: bash (via readline) has so many possibilities for completion. But a normal Linux distro can disturb the basic filename expansion with [tab] (or [tab][tab]) by adding option expansion. In my case it is the package "bash-completion" that gives me the behaviour described in the original Q.

It is not only a openvpn problem. Q says: "for example".

With bind -p | grep complete I get:

"\C-i": complete
"\e\e": complete
"\e!": complete-command
"\e/": complete-filename
"\e\C-i": dynamic-complete-history
"\eg": glob-complete-word
"\e*": insert-completions
# menu-complete (not bound)
"\C-x/": possible-filename-completions

This is where TAB = ctrl-i is bound to the basic complete function. The other bindings on my archlinux I just tried out. With "ta[esc][star]" I can get all commands starting with "ta" inserted on my command line.

The complete readline function is explained in man bash:


complete (TAB)

Attempt to perform completion on the text before point. Bash attempts completion treating the text as a variable (if the text begins with $), username (if the text begins with ~), hostname (if the text begins with @), or command (including aliases and functions) in turn. If none of these produces a match, filename completion is attempted.

I can only partly reproduce this. I think man bash forgets to mention it depends on whether you [tab] a first word or a 2nd, 3rd etc. word.

I have files starting with "ba" in my home/working dir. When I type "ba[tab]" at the prompt, I do not get these names, only commands from badblocks to bashbug. This is a sane behaviour: first word gives you commands, the following words filenames. And if you type "$[tab]" you really get a nice list of variable names.

Actually when I say [tab], I mean [tab][tab]. But we get so used to this that we don't even notice what this "complete" readline function all does. With the "complete-" variations you can control what is searched for (command, filename, variable) and what to do with the list if there is more than one match (possibility).

These readline functions come with many default bindings. Both man bash and man readline list the functions and their default bindings. To check use bind -p as above. This is also the basis for the ~/.inputrc file. I just made one (there was only a cryptic /etc/inputrc):

set colored-completion-prefix on
set colored-stats on

With colored-stats I get a colored list, as with ls --color. After "bi[tab][tab]" I see "bind" in white and "bison" in green, telling me that "bind" is not a executable (but a built-in...this is COMMAND expansion..."bind" is not even a filename!).

set show-all-if-ambiguous on

This controls tab vs. double tab. After I add it and type

cd s[tab]

I directly get a colored list of all FILE names. Directories, links, normal files etc. all appear in their own color.

These readline variables you can see with bind -v. To test a .inputrc change start a new bash with "bash", and then exit. Or Re-login.

The next layer is in /usr/share/bash-completion

It contains per command scripts, mostly from util-linux and systemd packages. There is a mount (2 Kb) and a systemctl (13 Kb) file. The mount-file is interesting: it gives you /proc/filesystems after you type "-t".

Normally after "mount -t [tab]" I get FILENAMES. After I source that "mount" file I really get fs types like ext2, ext3 and ext4. I go:

complete -r mount

to remove this feature. (THIS complete is a shell builtin command)

Third layer is that extra "bash-completion" package. I already deinstalled it after I had installed it for testing. With this package I got this nice feature of expanding options, and also package names. I could type "tar --[tab]" and i see all the options. But the filename expansion got lost in many constellations. Amd not only on archlinux.

This bash-completion package gave me a 2000-line script "bash_completion" and a lot of command files. The one for "tar" was 700 lines, full of functions. So fixing this is no solution.

If you really care for these [tab] complete subtleties, you have to start at the bottom and choose one or two readline functions other than complete to bind to other keys than [tab]. My default configuration above really works, but I have never used anything but [tab]. Now I want to set the right functions to the right keys. With or without that option-expanding bash-completion package.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .