这很奇怪。我在zsh
中定义了以下提示:
local user_host='%{$terminfo[bold]$fg[green]%}%n @ %m%{$reset_color%}'
local current_dir='%{$terminfo[bold]$fg[blue]%} %~%{$reset_color%}'
local git_branch='$(git_prompt_info)%{$reset_color%}'
local return_code="%(?..%{$fg[red]%}%? ↵%{$reset_color%})"
PROMPT="╭─${user_host} %D{[%a, %b %d %I:%M:%S]} ${current_dir} ${git_branch}
╰─%B$%b "
RPS1="${return_code}"
它适用于gnome-terminal
以及Emacs中的ansi-term
终端( M-x ansi-term
) - 请参阅以下示例:
但是,它在Emacs中的multi-term
下效果不佳,如下所示:
我认为multi-term
能够解释像gnome-terminal
或ansi-term
这样的终端所做的同一组转义字符。为什么不正确解释git-prompt_info
和其他人返回的转义字符?
我也尝试过:
set-terminal-coding-system
并将其设为utf-8-unix
TERM=eterm-color
,或者在调用Emacs等之前TERM=
,或者在调用Emacs等之前export TERM
.zshrc
到目前为止,最佳解决方案似乎是执行以下操作:
TERM=xterm-256color
但导致我在此报告的另一个问题:Passing escape sequences to shells within ansi-term in Emacs。
答案 0 :(得分:1)
为什么不解释返回的转义字符 git-prompt_info和其他人正确吗?
答案很可能是multi-term
不准备以任何理由接受那种格式的转义序列。这可能是配置问题,错误或故意。将模式设置为接受颜色,即TERM=xterm-256color
,可以改善情况,因为它接受类似于终端仿真器中使用的标准格式的颜色转义序列,例如:
RED='\033[0;31m'
NC='\033[0m' # No Color
echo "I ${RED}love${NC} Stack Overflow\n" # this output IS NOT interpreting the escapes
echo -e "I ${RED}love${NC} Stack Overflow\n" # this output IS interpreting them
显着部分是颜色的[0;31m
,在您的另一个问题的“更新2”中的链接线程中引用,询问打印出以4m
开头的行为什么这种颜色逃逸序列。
这里有更多info,附带相关摘录:
因此,您的终端模拟器可以理解颜色。您的 终端模拟器了解
\033[0;36m
是青色,而另一个 终端模拟器可能使用完全不同的字符集 对于青色(虽然没有理智的终端模拟器会标榜标准 这样做)。这就是tput
的原因。当您运行tput setaf 6
时,tput
将查找终端的转义码 颜色6(青色),以及转义代码的输出。
我怀疑,在你的另一个问题中, alt + b 和 alt + f 的原因是在你的另一个问题中工作是由于终端宽度计数被关闭,因为这些转义序列的解释不正确,这些转义应该是非打印或零宽度。我没有对multi-term
进行过多的讨论,但解决方案可能涉及使用tput
或类似方法来使其正确理解转义序列。