Як налагодити і виправити повільний автозаповнення в bash?


26

Після недавнього оновлення (Ubuntu 12.04 LTS) завершення TAB у командному рядку повільно. Після введення часткової команди (наприклад evi [TAB]) або часткового імені файлу (наприклад evince somedocu[TAB]) оболонка, іноді, але не завжди, зависає кілька секунд.

Особисто я віддаю перевагу менш потужному автозаповненню, ніж повільному. Є просте виправлення?

Редагувати: Додаткова інформація, що стосується коментарів:

  • PATH досить стандартний. ~ / bin має кілька скриптів bash

    $ echo $PATH
    /home/USERNAME/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
  • Кількість файлів у робочому каталозі менше 100.

  • Особливість автоматичного заповнення була особливо повільною після незвичної активності диска (оновлення системи). Таким чином, можливо, що перечитування / usr / bin та інших каталогів спричинило відставання.

4
Чи не ви включаєте керування швидкістю жорсткого диска з оновленням, і що автозаповнення чекає, коли диск прокинеться, щоб мати можливість обчислити автозавершення?
Вінсент Нівольє

2
Це залежить від того, скільки файлів у вашому поточному каталозі?
terdon

1
Що говорить # echo $ PATH? Якщо у вас на шляху багато (декілька десятків тисяч і більше) файлів у каталогах, це може бути причиною цього.
Стефан

Відповіді:


28

Я не знаю про виправлення - є всілякі речі, які можуть спричинити затримки. Але я можу запропонувати кілька порад для розслідування.

Як і здогадка, можливо, десь на шляху пошуку ( $PATHабо в якомусь місці, де Bash шукає дані про завершення), є файлова система, яка повільно реагує. Зазвичай це віддалені файлові системи, які повільні, але це також може бути несправний жорсткий диск, вивішений драйвер FUSE тощо.

Перший крок для дослідження - це виконати, set -xщоб отримати слід команд, які оболонка виконує для створення завершень. Подивіться, де це пауза.

Якщо це не дає достатньо інформації, принесіть великі гармати. Зверніть увагу на ідентифікатор процесу оболонки ( echo $$). В іншому терміналі запустіть strace -f -s9999 -p$$(або еквівалент страса, якщо працює на іншому ароматі Unix). Strace перераховує системні виклики, які виконує процес. Подивіться, чи здається, що ви отримуєте доступ до файлів, яких він не повинен робити, чи доступ до деяких файлів повільний. Додавання параметра -Tдо straceкомандного рядка змушує відображати час, витрачений у кожному системному виклику.


1
Протягом часу я користувався Unix і не знав про set -xте, яка класна команда. Дуже "хакерський режим займався"
Метт Флетчер

6
Ps, використовуйте set +xдля повернення до нормального режиму без налагодження
Метт Флетчер

19

Якщо ваше поле * nix налаштоване як клієнт LDAP, у вас може виникнути ця проблема, навіть увійшовши як локальний користувач.

Нудна інформація про налагодження: за допомогою налагодження set-xя виявив завершення, яке висить у:

> 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

Підтверджую: я підтвердив це, з чим ls ~*і повісив. Виявляється, мій сервер ldap був млявим, але це не повинно впливати на такі речі, як завершення bash та ls!

Рішення: Ага, є помилка, подана проти bash-завершення + ldap, вона буде виправлена ​​в більш новій версії та простим патчем, якщо ви не хочете чекати. Завершення вкладки знову швидко, ура!

Ось виправлений файл на випадок, якщо посилання відійде. Це просто втеча від ~ на рядках 545 і 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

Вам потрібно вийти з поточного сеансу ssh та повторно увійти, щоб цей патч набув чинності.


1
У мене була така точна проблема, і патч хороший
radman

2
Ту ж проблему тут (Debian 8.5) 2 1/3 роки раніше, і рішення працює як принадність. У Debian 8.6 немає проблеми.
ЙоМісмо

2
Я використовував набір -xa мільйон разів, але я ніколи не очікував, що він також покаже проблеми з виконанням робіт, велике спасибі!
Марч

Була ця проблема з debian 9.8!
Філіп Гачуд

0

Спробуйте перевстановити bash-завершення

sudo apt-get install --reinstall bash-completion

Для мене це виправлено в Ubuntu 18.04.3 LTS


0

Також деякі користуються додатковими автоматичними функціями, такими як Git bash auto complete . Повільність сповільнення Bash може бути результатом тих непоганих функцій автоматичного завершення.

У моєму випадку це був Git bash auto завершення, мій публічний ключ git був оновлений, тому він робив невдалу спробу аутентифікації, викликаючи зависання. Як тільки я видалив автоматичне завершення, воно знову було швидко. Тож моє рішення полягало в тому, щоб виправити свій ключ і знову включити його.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.