After a recent update (Ubuntu 12.04 LTS), TAB complete on the command line is slow. After entering a partial command (e.g evi [TAB]) or partial filename (e.g. evince somedocu[TAB]) the shell, sometimes though not always, hangs for several seconds.

Personally, I'd prefer a less powerfull autocomplete to a slow one. Is there a simple fix?

Edit: Additional information related to comments:

  • PATH is pretty standard. ~/bin has some bash scripts

    $ echo $PATH
  • The number of files in the working directory is less than 100.

  • The autocomplete feature was especially slow after unusual disk activity (system upgrade). It is, thus, possible, that rereading /usr/bin and other directories caused the lag.
  • 4
    isn't it that you enable your hard drive speed management with the update, and that the autocomplete waits for the disk to wake up to be able to compute the autocompletion ? Apr 2, 2013 at 14:43
  • 2
    Does it depend on how many files are in your current directory?
    – terdon
    Apr 2, 2013 at 15:02
  • 1
    What does # echo $PATH say? If you have many (several tens of thousands or more) of files in directories in your path, that might be causing it.
    – Stephan
    Apr 2, 2013 at 18:20

6 Answers 6


I don't know about fixing — there are all kinds of things that could go cause delays. But I can offer a few tips to investigate.

Just as a guess, maybe there's a directory somewhere in a search path ($PATH, or some place where bash looks for completion data) that's on a filesystem which is slow to respond. Usually it's remote filesystems that are slow, but it could also be a failing hard disk, a hung FUSE driver, etc.

The first step to investigate is to run set -x to get a trace of the commands that the shell executes to generate the completions. Watch where it pauses. When done, turn tracking back off with set +x.

If that doesn't give enough information, bring in the big guns. Note the shell's process ID (echo $$). In another terminal, run strace -f -s9999 -p$$ (or the equivalent of strace if running on another unix flavor). Strace lists the system calls performed by the process. See if it seems to be accessing files that it shouldn't, or if access to some files is slow. Adding the option -T to the strace command line makes it show the time spent in each system call.

  • 2
    The amount of time I've been using Unix and didn't know about set -x, what a cool command. Very "hacker mode engaged" Aug 7, 2018 at 10:37
  • 8
    Ps, use set +x to return to normal non-debug mode Aug 7, 2018 at 10:38
  • set -x does nothing strace shows nothing before or after the freeze. now what?????? Sep 1, 2020 at 18:23
  • @Arrow_Raider i had this same problem on one that was frozen, but check that your adding the correct pid. use ps aux to find the correct pid, and replace the $$ with that. otherwise if you monitor the incorrect pid, and not creating any activity on it, you wont see anything. Sep 29, 2021 at 20:38

If your *nix box is setup as an LDAP client you may have this problem, even logged in as a local user.

Boring debug info: Debugging with set-x, I found the completion that was hanging at:

> set -x
> ls foo<tab>
...                     <--- lots of output removed
+ _quote_readline_by_ref foo quoted
+ '[' -z foo ']'
+ [[ foo == \'* ]]      <--- froze here
+ [[ foo == ~* ]]       <--- actually causing the trouble

Confirm: I confirmed this with ls ~* which also hung. It turns out my ldap server was sluggish, but this shouldn't affect things like bash completion and ls!

Solution: Aha, there is a bug filed against bash-completion + ldap, it will be fixed in a newer version, and a simple patch if you don't want to wait. Tab completion is fast again, hooray!

Here's the patchfile in case the link goes away. It's merely escaping the ~ on lines 545 and 547:

--- /usr/share/bash-completion/bash_completion.orig 2014-11-06 10:36:14.981888369 +0100
+++ /usr/share/bash-completion/bash_completion  2014-11-06 10:36:25.142070963 +0100
@@ -542,9 +542,9 @@
     elif [[ $1 == \'* ]]; then
         # Leave out first character
         printf -v $2 %s "${1:1}"
-    elif [[ $1 == ~* ]]; then
+    elif [[ $1 == \~* ]]; then
         # avoid escaping first ~
-        printf -v $2 ~%q "${1:1}"
+        printf -v $2 \~%q "${1:1}"
         printf -v $2 %q "$1"

You need to exit current ssh session and re-login in order for this patch to take effect.

  • 1
    I had this exact problem and the patch is good
    – radman
    Feb 4, 2016 at 4:25
  • 2
    Same problem here (Debian 8.5) 2 1/3 years before and solution works like a charm. Debian 8.6 doesn't have the problem.
    – YoMismo
    Jan 5, 2017 at 8:08
  • 2
    I've used set -x a million times yet I never expected it to also show completion performance issues, thanks a lot!
    – MarcH
    Oct 3, 2017 at 17:31
  • Had this problem with debian 9.8! Feb 27, 2019 at 11:20
  • Debian 10 here: joined an Azure AD and exactly this patch solved the issue. thanks Feb 13, 2020 at 23:55

I recommend checking your system audio is properly working. The terminal bell sound not being able to play correctly might be the cause for the temporary freeze. For example: PulseAudio Daemon crashed / works incorrectly.

In my terminal when I first press the tab key, it became stuck for a seconds. After that it was fine. It also occurred if all text in terminal erased and the backspace key was pressed.

I tried all the above methods but they didn't work out.

Turn off Terminal Bell

Ctrl+Alt+T --> Edit --> Preference --> {User profile, usually unnamed} --> Text --> Sound --> Uncheck Terminal bell

  • 1
    Can't believe this is the root cause. I've been struggling for a while on my ubuntu18 server. Nov 10, 2020 at 14:15
  • Yes, it was the cause for me as well. Thanks for the solution! Jan 15, 2021 at 14:49
  • Thank you guys, I resolved the issue by checking the "Silence bell" option in iTerm. Settings > Profiles(Default) > Terminal > Notifications > ✅ Silence bell
    – Mekal
    Apr 18, 2023 at 0:40

Also some people use extra auto complete features like Git bash auto complete. Bash completion slowness can be a result of those extra auto complete features misbehaving.

In my case it was Git bash auto complete my git public key had been updated so it was doing a failing authentication attempt causing a hang. Once I removed the auto complete, it was fast again. So my solution was to fix my key and re-enable it.

  • How would you even determine this was happening? Sep 1, 2020 at 18:28
  • I tailed /etc logs then reproduced the issue. showed tons of errors. Jan 5, 2021 at 19:31
  • thanks, i use this too, and didnt consider that, cause it was something else on the system going awry. in the end Giles answer worked good for me Sep 29, 2021 at 20:41

Another strategy is to go through your Bash config files and deactivate all completion. Then test if it's faster. If it isn't faster, it's probably something related to a slow (remote) disk. But if it's faster, you can enable completions bit by bit until you found the one that caused the slowness.

I found that my /etc/bash.bashrc had this part:

if ! shopt -oq posix; then
  if [ -f /usr/share/bash-completion/bash_completion ]; then
    . /usr/share/bash-completion/bash_completion
  elif [ -f /etc/bash_completion ]; then
    . /etc/bash_completion

And my local ~/.bashrc had exactly the same. So the completion code got included twice and somehow that added a slowness when partially completing an ambiguous directory name.

  • this happens in wsl for ubuntu, just for ooglers Jun 3, 2020 at 19:25

Try to reinstall bash-completion

sudo apt-get install --reinstall bash-completion

For me this is fixed in Ubuntu 18.04.3 LTS

You must log in to answer this question.

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