从 ncurses 应用程序调用的脚本输出中的转义序列

Question

我目前正在我的家庭服务器上的 tmux 会话中运行 mcabber 作为我的 Jabber 客户端（使用 ncurses）。在本地，我将 iTerm2 作为终端模拟器运行，它支持通过字符转义序列触发咆哮通知。

注意：echo此问题中的所有内容都适用于printf %b, 或echo -e在 bash 和 GNU 中echo。

例如，echo "\e]9;foobar\007"使 iTerm2 发送带有文本“foobar”的 Growl 消息。

但是，在 tmux 会话中，转义序列会被吃掉。因此，\Ptmux可以像这样使用专有字符转义序列：

echo "\ePtmux;\e\e]9;foobar\007\e\\"

这会在 tmux 会话中触发咆哮消息。

但是，当我在收到新消息时触发的 mcabber 事件脚本中使用它时，不会触发任何通知，就像将回声发送到错误的终端一样。

我想这与触发脚本的 mcabber 是一个 ncurses 应用程序有关，因此我的普通 bash 脚本的输出丢失了，而 iTerm 2 永远看不到它。

我也尝试调用 smcup 没有成功，然后根据我发现的一些想法进行回应

tput smcup
echo "\ePtmux;\e\e]9;$FROM: $MSG\007\e\\"
tput rmcup

我想这不起作用，因为问题不是切换回“真实终端窗口”，而是更多地将输出定向到 ncurses 窗口。

关于这个有什么想法吗？

Answer 1

tmux 和 screen 程序不直接通过转义序列。它们向应用程序提供一种终端（屏幕终端类型），并且本身就是另一个终端的 ncurses 应用程序。实际上，它有点像终端翻译器。所以是的，它消耗（或丢弃）“屏幕”终端类型的序列，并建立一个您看到的缓冲区。然后它会获取这些缓冲区更改事件并使用您当前使用的任何类型的终端来显示当前缓冲区。所以原来的app和查看端是解耦的。