Como depurar e corrigir o autocompleto lento no bash?

Question

Após uma atualização recente (Ubuntu 12.04 LTS), a tecla TAB completa na linha de comando é lenta. Depois de inserir um comando parcial (por exemplo, evi [TAB] ) ou nome de arquivo parcial (por exemplo, evince somedocu[TAB] ), o shell, às vezes, nem sempre, trava por vários segundos.

Pessoalmente, prefiro um autocomplete menos poderoso para um lento. Existe uma solução simples?

Editar: informações adicionais relacionadas a comentários:

• O PATH é bastante normal. ~ / bin tem alguns scripts bash

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

• O número de arquivos no diretório de trabalho é menor que 100.

• O recurso de preenchimento automático ficou especialmente lento após a atividade incomum do disco (atualização do sistema). Assim, é possível que a releitura / usr / bin e outros diretórios causem o atraso.

Answer 1

Eu não sei sobre consertos - existem todos os tipos de coisas que podem causar atrasos. Mas posso oferecer algumas dicas para investigar.

Apenas como um palpite, talvez haja um diretório em algum lugar em um caminho de pesquisa ( $PATH , ou algum lugar onde o bash procura por dados de conclusão) que está em um sistema de arquivos que é lento para responder. Geralmente, são sistemas de arquivos remotos que são lentos, mas também podem ser um disco rígido com falha, um driver FUSE com problemas, etc.

O primeiro passo para investigar é executar set -x para obter um rastreamento dos comandos que o shell executa para gerar as conclusões. Veja onde ele pausa.

Se isso não der informação suficiente, traga as grandes armas. Observe o ID do processo do shell ( echo $$ ). Em outro terminal, execute strace -f -s9999 -p$$ (ou o equivalente de strace se estiver executando em outro tipo de unix). Strace lista as chamadas do sistema realizadas pelo processo. Veja se ele parece estar acessando arquivos que não deveria, ou se o acesso a alguns arquivos é lento. Adicionar a opção -T à linha de comando strace faz com que ela mostre o tempo gasto em cada chamada do sistema.

    

Answer 2

Se a sua caixa * nix estiver configurada como um cliente LDAP, você pode ter esse problema, mesmo logado como um usuário local.

Informações sobre depuração chata: Depuração com set-x , encontrei a conclusão pendente em:

> 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

Confirme: confirmei isso com ls ~* , que também foi suspenso. Acontece que meu servidor ldap estava lento, mas isso não deve afetar coisas como conclusão do bash e ls!

Solução: Aha, há um registro de bugs contra o bash-completion + ldap, ele será corrigido em uma versão mais recente e um patch simples se você não usar não quero esperar. A conclusão da tabulação é rápida novamente, viva!

Aqui está o patchpile, caso o link desapareça. É apenas escapar das linhas 545 e 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

Você precisa sair da sessão ssh atual e fazer o login novamente para que este patch tenha efeito.