Comment déboguer et corriger la saisie semi-automatique lente dans bash?

Après une récente mise à jour (Ubuntu 12.04 LTS), la TAB terminée sur la ligne de commande est lente. Après avoir entré une commande partielle (par exemple evi [TAB]) ou un nom de fichier partiel (par exemple evince somedocu[TAB]), le shell, parfois mais pas toujours, se bloque pendant plusieurs secondes.

Personnellement, je préfère une saisie semi-automatique moins puissante à une saisie lente. Existe-t-il une solution simple?

Modifier: Informations supplémentaires relatives aux commentaires:

• PATH est assez standard. ~ / bin a quelques 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 fonction de saisie semi-automatique était particulièrement lente après une activité inhabituelle du disque (mise à niveau du système). Il est donc possible que la relecture de / usr / bin et d'autres répertoires soient à l'origine du retard.

Je ne sais pas comment réparer - il y a toutes sortes de choses qui pourraient entraîner des retards. Mais je peux offrir quelques conseils pour enquêter.

Juste comme une supposition, il y a peut-être un répertoire quelque part dans un chemin de recherche ( $PATH, ou un endroit où bash cherche des données d'achèvement) qui se trouve sur un système de fichiers qui est lent à répondre. Ce sont généralement des systèmes de fichiers distants qui sont lents, mais il peut également s'agir d'un disque dur défaillant, d'un pilote FUSE bloqué, etc.

La première étape pour enquêter est d'exécuter set -xpour obtenir une trace des commandes que le shell exécute pour générer les complétions. Regardez où ça s'arrête.

Si cela ne donne pas suffisamment d'informations, apportez les gros canons. Notez l'ID de processus du shell ( echo $$). Dans un autre terminal, exécutez strace -f -s9999 -p$$(ou l'équivalent de strace si vous utilisez un autre type d'Unix). Strace répertorie les appels système effectués par le processus. Voyez s'il semble accéder à des fichiers qu'il ne devrait pas, ou si l'accès à certains fichiers est lent. L'ajout de l'option -Tà la straceligne de commande permet d'afficher le temps passé dans chaque appel système.

Si votre boîte * nix est configurée en tant que client LDAP, vous pouvez avoir ce problème, même connecté en tant qu'utilisateur local.

Informations de débogage ennuyeuses: Débogage avec set-x, j'ai trouvé l'achèvement qui pendait à:

> 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: j'ai confirmé cela avec ls ~*lequel également accroché. Il s'avère que mon serveur LDAP était lent, mais cela ne devrait pas affecter des choses comme l'achèvement de bash et ls!

Solution: Aha, un bogue a été déposé contre bash-complétion + ldap, il sera corrigé dans une version plus récente, et un simple patch 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îtrait. Il échappe simplement au ~ 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 en cours et vous reconnecter pour que ce correctif prenne effet.

Essayez de réinstaller bash-complètement

sudo apt-get install --reinstall bash-completion

Pour moi, cela est corrigé dans Ubuntu 18.04.3 LTS

Certaines personnes utilisent également des fonctionnalités de saisie automatique supplémentaires telles que la saisie automatique Git bash . La lenteur de la complétion de Bash peut être le résultat d'un mauvais comportement de ces fonctionnalités supplémentaires.

Dans mon cas, il s'agissait de Git bash auto complete, ma clé publique git avait été mise à jour, ce qui faisait échouer une tentative d'authentification provoquant un blocage. Une fois que j'ai supprimé la saisie automatique, elle a de nouveau été rapide. Ma solution a donc été de réparer ma clé et de la réactiver.