Почему эта подсказка bash иногда сохраняет часть предыдущих команд при прокрутке истории?

Question

Моя подсказка bash, которую я признаю, что она была украдена из нескольких мест и выложена вместе, иногда добавляет часть предыдущих команд к ее длине при прокрутке истории bash с помощью стрелок вверх / вниз.

Например, если мои предыдущие команды были:

ls
cd /home/caleb
vim .bashrc

Когда я был в моем приглашении и прокручивал его дважды, это могло выглядеть так:

$ vim .bcd /home /caleb

Где первые пять символов остались от последней команды.

У кого-нибудь есть идеи, почему это происходит и как это можно остановить?

Моя подсказка установлена с этим кодом (способ долго включать здесь): https://gist.github.com/1679352

Answer 1

Цветовые коды должны быть заключены в квадратные скобки. Скобки сообщают Bash, что текст не должен быть напечатан

основываясь на примере @ Phreditor, это показывает, что любое форматирование, выполненное после новой строки, приведет к исходной проблеме:

export PS1="\n\n\[\033[01;33m[\w]\033[00m\n\033[0;90m\$ "

перенос кода формата в [] гарантирует, что раздражающее поведение никогда не произойдет:

export PS1="\n\[\[\033[01;33m\][\w]\[\033[00m\]\n\[\033[0;90m\]\$ "

Документация: http://tldp.org/HOWTO/Bash-Prompt-HOWTO/nonprintingchars.html

Поскольку форматирование PS1 приводит к тому, что значение становится таким длинным и трудным для чтения, я помещаю коды формата в переменные:

BYELLOW='\[\033[01;33m\]'
IBLACK='\[\033[0;90m\]'
PS_CLEAR='\[\033[0m\]'
export PS1="\n${BYELLOW}[\w]${PS_CLEAR}\n${IBLACK}\$ "

Answer 2

У меня была такая же проблема, и она была связана с определениями цвета.

В моем случае у меня есть многострочная подсказка (дает большую часть места для текущей команды независимо от длины пути, отображаемой в подсказке).

Плохая версия:

export PS1="\n\n\[\033[01;33m[\w]\n\033[00m\$ "

Хорошая версия:

export PS1="\n\n\[\033[01;33m[\w]\033[00m\n\$ "

\033[00m завершает цвет. Если это после новой строки (\n), это препятствует правильному перерисовыванию в терминале, чтобы перезаписать предыдущие команды цветом фона. Перемещение за новой чертой решило проблему.

(используя терминал в Mac OS 10.8)

Answer 3

Где-то ваша подсказка fubar. Обычно происходит то, что ваша оболочка думает, что она выводит непечатаемые термины-коды и ожидает, что она займет место. Лучший совет, который я могу вам дать, - систематически добавлять (или убирать) ваше приглашение, пока это поведение не перестанет изолировать код, вызывающий эту проблему.

Answer 4

Я на самом деле думаю, что это связано с отсутствующим разделителем «непечатный символ». У меня была точно такая же проблема, но перемещение ее до новой строки (\n) не устранило ее. Вместо этого я правильно окружил все непечатаемые символы (здесь, команды окраски) '\[' и '\]'.

Плохо (работает, но имеет проблему с историей, описанную выше):

PS1="\e[32m\u\e[35m@\e[32m\h \e[33m\w\e[36m\n\$\e[0m"

Хорошо (окружены все цветовые команды символами '\[' и '\]' - не показывает историю запутанных команд):

PS1="\[\e[32m\]\u\[\e[35m\]@\[\e[32m\]\h \[\e[33m\]\w\[\e[36m\]\n\$\[\e[0m\]"

i.e. "\e[...m" --becomes--> "\[\e[...m\]"

И если вы помещаете это в что-то вроде SecureCRT для автоматической отправки при входе в систему, вам, возможно, придется дважды экранировать все (ставить двойные обратные слеши везде), если система автоматического входа использует сам первый обратный слеш для определения отправляемого символа :

PS1="\\[\\e[32m\\]\\u\\[\\e[35m\\]@\\[\\e[32m\\]\\h \\[\\e[33m\\]\\w\\[\\e[36m\\]\\n\\$\\[\\e[0m\\]"

i.e. "\..." --becomes--> "\\..."

(Это определенно верно для SecureCRT и может быть справедливо для других, таких как PuTTY или TeraTerm - тестирование требуется с вашей стороны.)