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.
bash
autocomplete
Jan
źródło
źródło
Odpowiedzi:
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 (
$PATH
lub 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 -x
celu 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 uruchomstrace -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-T
dostrace
wiersza poleceń powoduje, że pokazuje czas spędzony w każdym wywołaniu systemowym.źródło
set -x
, co za fajne polecenie. Bardzo „włączony tryb hakera”set +x
aby powrócić do normalnego trybu bez debugowaniaJeś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-x
znalazłem zakończenie, które wisiało na: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:
Musisz wyjść z bieżącej sesji ssh i ponownie się zalogować, aby łatka zaczęła obowiązywać.
źródło
Spróbuj ponownie zainstalować zakończenie bash
Dla mnie jest to naprawione w Ubuntu 18.04.3 LTS
źródło
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.
źródło