Sign up ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

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.
share|improve this question
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 ? – Vincent Nivoliers Apr 2 '13 at 14:43
Does it depend on how many files are in your current directory? – terdon Apr 2 '13 at 15:02
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 '13 at 18:20

2 Answers 2

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.

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.

share|improve this answer

If your *nix box is setup as an LDAP client you may have this problem, even logged in as a local user. 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 == \'* ]]      <--- actually froze here
+ [[ foo == ~* ]]       <--- causing the trouble, I believe

(Actually, it was hanging just before this line -- irritatingly it must print the line it has just completed.)

I confirmed this with ls ~* which also hung. I ensured my LDAP server was online and adjusted my LDAP timeout parameters to resolve it.

I'm still investigating what this line even does in bash completion, and whether/how I can remove it.

Update: 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!

share|improve this answer
The patch seems to be working well, thanks! – amertkara Sep 10 at 19:19

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.