When you are typing a bad command, say you want to do:

$ cd ..
$ ls

But instead you type too fast and end up hitting enter between l and s, so you get:

$ cd ..
$ l
sbash: l: command not found...

This happens all the time of course, when we type fast. What I'm curious about is the source of the 2.5 second (on my system) pause after the bad command text appears on the screen. Seems to me it recognizes the bad command instantly, prints error message about it, but then just for fun waits 2.5 seconds before returning me to the command line. What causes this? Is there a way fix to this? It's a small annoyance, but I'd like to get rid of it. :)

Edit: Running Fedora 16 system

  • You forgot to mention what OS you're on.
    – Daniel Beck
    Feb 26, 2012 at 9:35
  • whoa, you don't alias l to ls? :)
    – dotjoe
    Feb 26, 2012 at 20:31

3 Answers 3


This type of behavior is caused by a tool frequently installed on some distributions that hook into bash. This hook makes it so that if you try to run a command, and the command doesn't exist, then bash will search the files available in the configured repositories, and tell you what package you would need to install to get that command.

If you are not on a Debian system you'll want to look at your bash startup files profiles and so on and see if anything defines the function named command_not_found_handle. If that bash function is defined, then it will be called whenever you run a command and an appropriate program cannot be found in your search path. If you run typset | less and browse through the output you will see the command_not_found_handle() function if it has been defined.

On Debian/Ubuntu the package that provides this behavior is command-not-found. If you purge that, then you will disable the lookups which does slow things down.

Here is an example

# command-not-found installed
$ time pwgen
The program 'pwgen' is currently not installed.  To run 'pwgen' please ask your administrator to install the package 'pwgen'
pwgen: command not found

real    0m0.074s
user    0m0.032s
sys     0m0.040s

# purge command-not-found and restart bash
$ time pwgen
-bash: pwgen: command not found

real    0m0.002s
user    0m0.000s
sys     0m0.000s

The exact time would of course be different for you. I ran my tests on a pretty beefy server.

  • 10
    In my case in fedora, it turned out to be a package called: PackageKit-command-not-found
    – Fuu
    Feb 26, 2012 at 10:07

Part of the question was "is there a way to fix this (in Fedora)?" There is: at the bottom of your .bashrc file add the command

unset command_not_found_handle

You probably want to do it at the end of your .bashrc (or close to it) because you might be running /etc/bashrc or other bash scripts at the top of your .bashrc.


On fedora, this behaviour can be controlled by changing the /etc/PackageKit/CommandNotFound.conf configuration file.

Setting SoftwareSourceSearch=false will get rid of the delay since it will not try to locate a package with the missing command using the package manager.

You can also change the amount of time it will wait for a package search instead by changing the MaxSearchTime=2000 option to indicate the number of milliseconds you are willing to wait for the package search to return a match. I find that the default of 2 seconds is not long enough to return any matches and just causes an unwanted delay when you have a typo.

Either bump up the MaxSearchTime to provide useful output or disable SoftwareSourceSearch to eliminate the delay altogether.

You must log in to answer this question.

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