Jak debugować i naprawić powolne autouzupełnianie w bash?


26

Po ostatniej aktualizacji (Ubuntu 12.04 LTS), uzupełnianie TAB w wierszu poleceń jest powolne. Po wprowadzeniu częściowego polecenia (np. evi [TAB]) Lub częściowej nazwy pliku (np. evince somedocu[TAB]) Powłoka, choć nie zawsze, zawiesza się na kilka sekund.

Osobiście wolałbym mniej wydajne autouzupełnianie niż wolne. Czy istnieje prosta poprawka?

Edycja: Dodatkowe informacje związane z komentarzami:

  • ŚCIEŻKA jest dość standardem. ~ / bin ma kilka skryptów bash

    $ echo $PATH
    /home/USERNAME/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
    
  • Liczba plików w katalogu roboczym jest mniejsza niż 100.

  • Funkcja autouzupełniania była szczególnie powolna po nietypowej aktywności dysku (aktualizacja systemu). Jest zatem możliwe, że ponowne odczytanie / usr / bin i innych katalogów spowodowało opóźnienie.

4
czy nie jest tak, że włączasz zarządzanie prędkością dysku twardego za pomocą aktualizacji i że autouzupełnianie czeka, aż dysk się obudzi, aby móc obliczyć autouzupełnianie?
Vincent Nivoliers

2
Czy to zależy od liczby plików w twoim bieżącym katalogu?
terdon

1
Co mówi # echo $ PATH? Jeśli masz wiele (kilkadziesiąt tysięcy lub więcej) plików w katalogach na swojej ścieżce, może to być przyczyną.
Stephan

Odpowiedzi:


28

Nie wiem o naprawianiu - są różne rzeczy, które mogą powodować opóźnienia. Ale mogę zaoferować kilka wskazówek do zbadania.

Tak jak przypuszczam, być może gdzieś w ścieżce wyszukiwania ( $PATHlub w innym miejscu, w którym bash szuka danych ukończenia) znajduje się system plików, który reaguje wolno. Zwykle są to powolne zdalne systemy plików, ale może to być również uszkodzony dysk twardy, zawieszony sterownik FUSE itp.

Pierwszym krokiem do zbadania jest uruchomienie w set -xcelu uzyskania śladu poleceń wykonywanych przez powłokę w celu wygenerowania uzupełnień. Zobacz, gdzie się zatrzymuje.

Jeśli to nie daje wystarczającej ilości informacji, przynieś duże pistolety. Zanotuj identyfikator procesu powłoki ( echo $$). W innym terminalu uruchom strace -f -s9999 -p$$(lub ekwiwalent strace, jeśli działa na innym uniksowym smaku). Strace wyświetla wywołania systemowe wykonywane przez proces. Sprawdź, czy wydaje się, że uzyskuje dostęp do plików, których nie powinien, lub czy dostęp do niektórych plików jest powolny. Dodanie opcji -Tdo stracewiersza poleceń powoduje, że pokazuje czas spędzony w każdym wywołaniu systemowym.


1
Ile czasu używałem Unixa i nie wiedziałem set -x, co za fajne polecenie. Bardzo „włączony tryb hakera”
Matt Fletcher,

6
Ps, użyj, set +xaby powrócić do normalnego trybu bez debugowania
Matt Fletcher,

19

Jeśli Twoje pole * nix jest skonfigurowane jako klient LDAP, możesz mieć ten problem, nawet zalogowany jako użytkownik lokalny.

Nudne informacje debugowania: Podczas debugowania set-xznalazłem zakończenie, które wisiało na:

> 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

Potwierdź: Potwierdziłem to, z ls ~*którym również się zawiesiłem. Okazuje się, że mój serwer ldap był powolny, ale nie powinno to wpływać na takie rzeczy jak ukończenie basha i ls!

Rozwiązanie: Aha, zgłoszono błąd dotyczący zakończenia bash + ldap, zostanie on naprawiony w nowszej wersji i prosta łatka, jeśli nie chcesz czekać. Wypełnianie kart znów jest szybkie, hura!

Oto plik łatki na wypadek, gdyby link zniknął. Po prostu ucieka ~ w liniach 545 i 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

Musisz wyjść z bieżącej sesji ssh i ponownie się zalogować, aby łatka zaczęła obowiązywać.


1
Miałem dokładnie ten problem i łatka jest dobra
radman

2
Ten sam problem tutaj (Debian 8.5) 2 1/3 lat wcześniej i rozwiązanie działa jak urok. Debian 8.6 nie ma problemu.
YoMismo,

2
Użyłem zestawu -xa milion razy, ale nigdy nie spodziewałem się, że pokaże on również problemy z wydajnością ukończenia, wielkie dzięki!
MarcH

Miałem ten problem z debianem 9.8!
Philippe Gachoud

0

Spróbuj ponownie zainstalować zakończenie bash

sudo apt-get install --reinstall bash-completion

Dla mnie jest to naprawione w Ubuntu 18.04.3 LTS


0

Również niektóre osoby używają dodatkowych funkcji automatycznego uzupełniania, takich jak Git bash auto complete . Powolność ukończenia bashu może wynikać z nieprawidłowego zachowania dodatkowych funkcji automatycznego uzupełniania.

W moim przypadku było to automatyczne ukończenie Git bash. Mój klucz publiczny git został zaktualizowany, więc nie powiodła się próba uwierzytelnienia, powodując zawieszenie. Gdy usunąłem autouzupełnianie, znów było szybkie. Więc moim rozwiązaniem było naprawić mój klucz i włączyć go ponownie.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.