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

29

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

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

ls
cd /home/caleb
vim .bashrc

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

$ vim .bcd / home / caleb

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

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

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

bash prompt Калеб Томпсон
источник
1
Установите PS1 в значение без всякой хрени vcs и посмотрите, что произойдет. Это мое предположение.
Даниэль Бек
Вы уже нашли виновника в своем запросе? У меня та же проблема.
Acme
Да, bash теряет его по цветам и не может отделить длину строк с помощью цветовых переходов от длины видимой строки. Это то, к чему стремился SiegeX. Я закончил тем, что переключился на ZSH и использовал другое приглашение. ZSH не имеет такой же проблемы.
Калеб Томпсон
1
Оба предыдущих ответа не решили мою проблему и не дали объяснения, почему это произошло. Пожалуйста, проверьте, что приглашение Custom Bash перезаписывается само , если у кого-то есть поиск к этой точке.
D3Hunter
Связанная проблема unix.stackexchange.com/questions/105958/…
matthiasbe

Ответы:

6

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

SiegeX
источник
36

Цветовые коды должны быть заключены в квадратные скобки. Скобки сообщают 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}\$ "
m79lkm
источник
3
Это должен быть принятый ответ. Решил вопрос.
Atcold
1
Следует отметить (потому что я этого не заметил;)), что в этом беспорядке обратной косой черты и квадратных скобок квадратные скобки, которые следуют за escape-последовательностью, \033НЕ должны быть исключены. Избегать только квадратных скобок.
Бенджам
Для меня непонятно, как разобраться со всеми этими спецсимволами, использование первого результата Google помогло создать рабочее приглашение именно так, как я этого хотел: ezprompt.net
Mallox
Я хотел настроить свои быстрые цвета для ГОД, но никогда не делал, так как у меня всегда была эта проблема! Я никогда не мог понять, почему, поэтому я просто остановился и держал все белое ... Я просто настраивал новый компьютер, и в конце концов меня осенило, что на самом деле Google решил эту проблему ... Так рад, что сделал! Спасибо за этот замечательный урок.
TylerH4
8

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

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

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

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)

Phreditor
источник
Это определило проблему для меня, в то время как текущий принятый ответ был слишком общим.
Брайан
Это более точный ответ, и он должен быть победителем (а также решением моей проблемы).
Craveytrain
\nтоже был виновником для меня. Спасибо!
Mhulse
3

Я на самом деле думаю, что это связано с отсутствующим разделителем непечатного символа. У меня была точно такая же проблема, но перемещение ее до новой строки (\ 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 - тестирование требуется с вашей стороны.)

skeetastax
источник