¿Qué causa que bash se detenga después de un mal comando?

Cuando esté escribiendo un comando incorrecto, diga que desea hacer:

$ cd ..
$ ls

Pero en su lugar, escribe demasiado rápido y termina presionando enter entre ly s, por lo que obtiene:

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

Esto sucede todo el tiempo, por supuesto, cuando escribimos rápido. Lo que me interesa es la fuente de la pausa de 2.5 segundos (en mi sistema) después de que aparezca el texto de comando incorrecto en la pantalla. Me parece que reconoce el comando incorrecto al instante, imprime un mensaje de error al respecto, pero luego, solo por diversión, espera 2.5 segundos antes de regresarme a la línea de comando. ¿Qué causa esto? ¿Hay alguna forma de solucionar esto? Es una pequeña molestia, pero me gustaría deshacerme de ella. :)

Editar: Ejecutar el sistema Fedora 16

Este tipo de comportamiento es causado por una herramienta frecuentemente instalada en algunas distribuciones que se conectan a bash. Este enlace hace que si intenta ejecutar un comando, y el comando no existe, bash buscará los archivos disponibles en los repositorios configurados y le dirá qué paquete necesitaría instalar para obtener ese comando.

Si no está en un sistema Debian, querrá ver los perfiles de los archivos de inicio de bash, etc., y ver si algo define la función nombrada command_not_found_handle. Si esa función bash está definida, se llamará siempre que ejecute un comando y no se encuentre un programa apropiado en su ruta de búsqueda. Si ejecuta typset | lessy navega por la salida, verá la command_not_found_handle()función si se ha definido.

En Debian / Ubuntu, el paquete que proporciona este comportamiento es el comando no encontrado . Si purga eso, deshabilitará las búsquedas, lo que ralentizará las cosas.

Aquí hay un ejemplo

# 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

La hora exacta, por supuesto, sería diferente para usted. Ejecuté mis pruebas en un servidor bastante robusto.

Parte de la pregunta era "¿hay alguna manera de arreglar esto (en Fedora)?" Hay: en la parte inferior de su archivo .bashrc agregue el comando

unset command_not_found_handle

Probablemente desee hacerlo al final de su .bashrc (o cerca de él) porque podría estar ejecutando / etc / bashrc u otros scripts de bash en la parte superior de su .bashrc.

En fedora, este comportamiento se puede controlar cambiando el /etc/PackageKit/CommandNotFound.confarchivo de configuración.

La configuración SoftwareSourceSearch=falseeliminará el retraso ya que no intentará localizar un paquete con el comando que falta utilizando el administrador de paquetes.

También puede cambiar la cantidad de tiempo que esperará una búsqueda de paquete cambiando la MaxSearchTime=2000opción para indicar la cantidad de milisegundos que está dispuesto a esperar para que la búsqueda de paquete devuelva una coincidencia. Creo que el valor predeterminado de 2 segundos no es lo suficientemente largo como para devolver coincidencias y solo causa un retraso no deseado cuando tiene un error tipográfico.

O suba MaxSearchTimepara proporcionar una salida útil o desactívela SoftwareSourceSearchpara eliminar el retraso por completo.