web-dev-qa-db-fra.com

Comment déboguer et réparer le lent automatique à bash?

Après une mise à jour récente (Ubuntu 12.04 LTS), l'onglet complète sur la ligne de commande est lente. Après avoir entré une commande partielle (E.g evi [TAB]) ou nom de fichier partiel (par exemple evince somedocu[TAB]) La coquille, parfois bien que pas toujours, se bloque pendant plusieurs secondes.

Personnellement, je préférerais une autoocomplète moins puissante à un lent. Y a-t-il une solution simple?

Edit : Informations complémentaires relatives aux commentaires:

  • Le chemin est assez standard. ~/bin a des scripts Bash

    $ echo $PATH
/home/USERNAME/bin:/usr/local/bin:/usr/bin:/bin:/usr/games

  • Le nombre de fichiers dans le répertoire de travail est inférieur à 100.

  • La fonctionnalité Autocomplecte était particulièrement lente après une activité de disque inhabituelle (mise à niveau du système). Il est donc possible que la relecture/usr/bin et d'autres répertoires ont provoqué le décalage.
bashautocomplete
27
Jan

Je ne sais pas de la réparation - il y a toutes sortes de choses qui pourraient faire des retards. Mais je peux offrir quelques conseils pour enquêter.

Tout comme devinez, peut-être qu'il y a un répertoire quelque part dans un chemin de recherche ($PATH, ou un endroit où Bash recherche des données d'achèvement) sur un système de fichiers qui est lent à répondre. Habituellement, ce sont des systèmes de fichiers distants lents, mais il pourrait également s'agir d'un disque dur défaillant, d'un pilote de fusible suspendu, etc.

La première étape pour enquêter est de courir set -x Pour obtenir une trace des commandes que la Shell exécute pour générer les achèvements. Regardez où il fait une pause.

Si cela ne donne pas assez d'informations, apportez les gros canons. Notez l'ID de processus de la coque (echo $$). Dans un autre terminal, courez strace -f -s9999 -p$$ (ou l'équivalent de strace Si elle fonctionne sur une autre saveur UNIX). Strace répertorie les appels système effectués par le processus. Voir si cela semble accéder aux fichiers qu'il ne faut pas ou si l'accès à certains fichiers est lent. Ajout de l'option -T à la ligne de commande strace permet de montrer le temps passé dans chaque appel système.

29
Gilles 'SO- stop being evil'

Si votre * NIX Box est configuré en tant que client LDAP, vous pouvez avoir ce problème, même connecté en tant qu'utilisateur local.

Info de débogage ennuyeux: Débogage avec set-x, J'ai trouvé l'achèvement qui était suspendu à:

> 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

Confirmer: Je l'ai confirmé avec ls ~* qui a également accroché. Il s'avère que mon serveur LDAP était lent, mais cela ne devrait pas affecter les choses comme Bash Achion et LS!

solution: AHA, il y a un bug classé contre Bash-achèvement + LDAP, il sera corrigé dans une version plus récente, et a patch simple Si vous ne voulez pas attendre. L'achèvement de l'onglet est à nouveau rapide, Hourra!

Voici le patchfile au cas où le lien disparaît. Il ne fait que s'échapper sur les lignes 545 et 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}"
     else
         printf -v $2 %q "$1"
     fi

Vous devez quitter la session SSH actuelle et la reconnexion pour que ce correctif prenne effet.

20
Jeff Ward

Une autre stratégie consiste à parcourir vos fichiers de configuration Bash et à désactiver tout achèvement. Puis test si c'est plus rapide. Si ce n'est pas plus rapide, c'est probablement quelque chose lié à un disque lent (distant). Mais si c'est plus rapide, vous pouvez activer la fin des termes jusqu'à ce que vous ayez trouvé celui qui a provoqué la lenteur.

J'ai trouvé que mon /etc/bash.bashrc avait cette partie:

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
  fi
fi

Et mon local ~/.bashrc avait exactement la même chose. Donc, le code d'achèvement a été inclus deux fois et d'une manière ou d'une autre qui a ajouté une lenteur lorsqu'elle achève partiellement un nom de répertoire ambigu.

1
maikel

Essayer de réinstaller Bash-achèvement

Sudo apt-get install --reinstall bash-completion

Pour moi, cela est fixé à Ubuntu 18.04.3 LTS

0
arulraj.net

De plus, certaines personnes utilisent des fonctionnalités complètes automatiques supplémentaires telles que Git Bash Auto complète . La lenteur d'achèvement de Bash peut être le résultat de ces caractéristiques complètes supplémentaires automatiques.

Dans mon cas, c'était Git Bash Auto complète ma clé publique GIT avait été mise à jour afin qu'elle effectuait une tentative d'authentification défaillante, ce qui entraîne une suspension. Une fois que j'ai supprimé la complète automatique, c'était à nouveau rapide. Donc, ma solution était de réparer ma clé et de le réactiver.

0
Nicholas DiPiazza