Согласно этому сообщению в списке рассылки ядра Linux, это не должно означать проблему:
Если Вы ничего не должны использовать на SMBus (аппаратные датчики, по существу) Вы не должны волноваться о том. Это означает, что ядро обнаружило, что BIOS может потенциально получить доступ к контроллеру SMBus, который может конфликтовать с использованием контроллера из ОС.
Нет никакой проблемы с \n
. Это - все снова и снова старая проблема длины escape-последовательности: \e[0m
и подобный не способствуют фактической длине подсказки, таким образом, необходимо включить их в \[
..\]
указать на это к интерпретатору:
PS1="\[\e[0;36m\]\h\[\e[m\] \[\e[0;33m\]\w/\[\e[m\]\n \[\e[0;31m\]\$ →\[\e[m\] "
Использовать $PROMPT_COMMAND
отобразить дополнительную строку, таким образом, Вы имеете нет \n
в $PS1
.
Более простая опция состоит в том, чтобы использовать tput
последовательности:
export PS1='\[$(tput setaf 4)\]\h\[$(tput sgr0)\] \[$(tput setaf 3)\]\w/\[$(tput sgr0)\]\n\[$(tput setaf 1)\]\$ →\[$(tput sgr0)\] '
tput
не, кажется, добавляет что-либо специальное для решения расчета длины: pastebin.com/u28RTT5t
– manatwork
03.04.2013, 15:37