Como depurar e corrigir o preenchimento automático lento no bash?

26

Após uma atualização recente (Ubuntu 12.04 LTS), o TAB completo na linha de comando fica lento. Depois de inserir um comando parcial (por exemplo evi [TAB]) ou nome de arquivo parcial (por exemplo evince somedocu[TAB]), o shell, às vezes, embora nem sempre, trava por alguns segundos.

Pessoalmente, eu prefiro um preenchimento automático menos poderoso a um lento. Existe uma solução simples?

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

  • PATH é bastante padrão. ~ / 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 atividades incomuns no disco (atualização do sistema). É, portanto, possível, que reler / usr / bin e outros diretórios tenham causado o atraso.
bash autocomplete Jan
fonte
4
não é que você habilita o gerenciamento de velocidade do disco rígido com a atualização e que o preenchimento automático aguarda a ativação do disco para poder calcular o preenchimento automático?
Vincent Nivoliers
2
Depende de quantos arquivos estão no seu diretório atual?
terdon
11
O que diz # echo $ PATH? Se você tiver muitos (várias dezenas de milhares ou mais) de arquivos em diretórios em seu caminho, isso pode estar causando isso.
Stephan

Respostas:

28

Não sei como consertar - existem todos os tipos de coisas que podem causar atrasos. Mas posso oferecer algumas dicas para investigar.

Apenas como um palpite, talvez exista um diretório em algum lugar no caminho de pesquisa ( $PATHou em algum lugar em que o bash procure por dados de conclusão) que esteja em um sistema de arquivos que demore a responder. Geralmente, os sistemas de arquivos remotos são lentos, mas também pode ser um disco rígido com falha, um driver FUSE travado, etc.

A primeira etapa a investigar é executar set -xpara rastrear os comandos que o shell executa para gerar as conclusões. Observe onde ele faz uma pausa.

Se isso não der informações suficientes, leve as armas grandes. Observe o ID do processo do shell ( echo $$). Em outro terminal, execute strace -f -s9999 -p$$(ou o equivalente a strace se estiver executando em outro sabor unix). Strace lista as chamadas do sistema realizadas pelo processo. Veja se parece estar acessando arquivos que não deveria ou se o acesso a alguns arquivos é lento. A adição da opção -Tà stracelinha de comando mostra o tempo gasto em cada chamada do sistema.

Gilles 'SO- parar de ser mau'
fonte
11
A quantidade de tempo que eu uso o Unix e não sabia set -x, que comando legal. Muito "modo de hackers envolvidos"
Matt Fletcher
6
Ps, uso set +xpara voltar ao modo não-depuração normais
Matt Fletcher
19

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

Informações de depuração chatas: depurando com set-x, encontrei a conclusão que estava pendurada 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: eu confirmei isso com o ls ~*qual também penduramos. Acontece que meu servidor ldap estava lento, mas isso não deve afetar coisas como a conclusão do bash e o ls!

Solução: Ah, existe um bug arquivado no bash-conclusão + ldap, ele será corrigido em uma versão mais recente e um patch simples, se você não quiser esperar. A conclusão da guia é rápida novamente, viva!

Aqui está o patchfile no caso de o link desaparecer. É apenas escapar do ~ nas 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 efetuar login novamente para que esse patch entre em vigor.

Jeff Ward
fonte
11
Eu tive esse problema exato eo patch é bom
radman
2
O mesmo problema aqui (Debian 8.5) 2 1/3 anos antes e a solução funciona como um encanto. O Debian 8.6 não tem o problema.
YoMismo 5/17
2
Eu usei set -xa milhões de vezes, mas nunca esperei que ele também mostrasse problemas de desempenho de conclusão, muito obrigado!
Março
Teve este problema com o debian 9.8!
Philippe Gachoud
0

Tente reinstalar a conclusão do bash

sudo apt-get install --reinstall bash-completion

Para mim, isso é corrigido no Ubuntu 18.04.3 LTS

arulraj.net
fonte
0

Além disso, algumas pessoas usam recursos extras automáticos extras, como o Git bash auto complete . A lentidão na conclusão da festança pode ser o resultado desses comportamentos extras de conclusão automática automática.

No meu caso, foi o Git bash auto complete, minha chave pública git havia sido atualizada e estava fazendo uma tentativa de autenticação com falha, causando um travamento. Depois que eu removi o auto complete, ele foi rápido novamente. Portanto, minha solução foi consertar minha chave e reativá-la.

Nicholas DiPiazza
fonte