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

我目前正在我的家庭服务器上的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却看不到它。

在回应发现的一些想法之前，我还尝试打电话给打sm而未成功

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

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

关于这个有什么想法吗？

事件脚本未能发送“咆哮者”消息的原因是，它在运行事件命令时mcabber关闭了标准输入，输出和错误流。您可以在中看到此内容hooks.c：

  if ((pid=fork()) == -1) {
    scr_LogPrint(LPRINT_LOGNORM, "Fork error, cannot launch external command.");
    g_free(datafname);
    return;   
  }    
  if (pid == 0) { // child
    // Close standard file descriptors
    close(STDIN_FILENO);
    close(STDOUT_FILENO);
    close(STDERR_FILENO);
    if (execl(extcmd, extcmd, arg_type, arg_info, bjid, arg_data,
              (char *)NULL) == -1) {
      // scr_LogPrint(LPRINT_LOGNORM, "Cannot execute external command.");
      exit(1);
    }
  }
  g_free(datafname);

这样一来，事件脚本就能在不干扰所使用的流的情况下运行mcabber。

没有特殊的ncurses模式来拦截消息（毕竟，tmux它已经作为terminfo应用程序运行了）。您可能可以通过将echo（最好是printf）重定向到来解决此问题/dev/tty，例如，

#!/bin/sh
printf '\033Ptmux;\033\033]9;foobar\007\033\\' >/dev/tty

tmux和screen程序不会直接通过转义序列。它们向应用程序提供一种终端（屏幕终端类型），而对另一终端本身就是ncurses应用程序。实际上，它类似于终端翻译器。因此，是的，它消耗（或丢弃）“屏幕”终端类型的序列，并建立一个您看到的缓冲区。然后，它将接收那些缓冲区更改事件，并使用您当前正在使用的任何类型的终端来显示当前缓冲区。因此，原始应用程序和查看终端是分离的。

如果你要放像...

export "PTTY=$(tty)"

... /etc/profile然后在-l您要调用的每个新的ogin外壳程序中（这通常是在打开新的终端窗口时发生的情况），环境变量将对其所有子进程可用-该环境变量应包括tmux及其所有子进程。

这应该使您能够...

printf '\033]9;foobar\007' >"$PTTY"

...从而跳过pty当前外壳和正在使用的终端仿真器之间可能存在的任何层。

如果问题是您的bash脚本的输出丢失了，那么您可以通过重定向赢得胜利：

回声“ \ ePtmux; \ e \ e] 9; foobar \ 007 \ e \”> / dev / tty

但是，我怀疑真正的问题是您应该使用echo -ebash处理字符串中的转义序列。