事情的起因是这样子的。

有一个非常常用的调试工具叫 strace。输出的信息是纯文本，一大片看起来累。在 Vim 里可以给它高亮一下，就好看多了。再加上各种搜索、清理，以及非常赞的 mark.vim 插件，用起来就舒服多了！

然而我并不想每次都让 strace 写到文件里然后再拿 Vim 去读，因为还得记着清理那些文件。如果数据量不大的话，直接通过管道传给 Vim 多好。

于是有了如下 zsh 函数：

(( $+commands[strace] )) && strace () { (command strace "$@" 3>&1 1>&2 2>&3) | vim -R - }

效果是达到了，但是这样子要中断 strace 的话，得去另一个终端里去 kill。按 Ctrl-C 的话，SIGINT 也会被发给 Vim，导致 Vim 显示空白。

所以嘛，得把 Vim 放到一个单独的进程组里，这样就不会在 Ctrl-C 的时候收到 SIGINT 了。但是，Vim 还得用终端啊。

一开始，我用自制的 expect.py 模块，给 Vim 分配了一个新的终端。这样子 Ctrl-C 好用了。然后我发现 Ctrl-Z 不好用了……

Ctrl-Z 还是挺方便的功能，临时需要执行个命令，不用开新的 shell（以及 ssh），直接按一下 Ctrl-Z，完事之后再回来，多好啊！就跟 zsh 的 Alt-q 一样方便好用呢。

于是就想还是不开 pty 了。直接子进程放新组里跑。这样 Vim 在尝试向终端输出时会收到 SIGTTOU 信号，因为它不是前台进程组。找了一下，用 tcsetpgrp 就可以把指定进程组放到前台了。然后发个 SIGCONT 让可能已经停下来了的 Vim 继续。

然后，当 Vim 收到 SIGTSTP 而停止的时候，我的程序该怎么知道呢？搜了一下，原来这种情况下也会收到 SIGCHLD 的！我以前一直以为只有子进程退出才会收到 SIGCHLD 啊……然后是一个关于 SIGCHLD 的坑，之前在 pssh 里看到过的，这次没有及时想到：不给 SIGCHLD 注册信号处理器时是收不到 SIGCHLD 的！不过诡异的是，我的这个程序有时却能够收到——在我使用 strace 跟踪它的时候……

于是，当 Vim 收到 SIGTSTP 时，把我们自己设置成前台进程组，然后给自己发一个 SIGTSTP 也停下来好了。令人意外的是，后台进程在调用 tcsetpgrp 时竟然也会收到 SIGTTOU。不过没关系，忽略掉就好了。

当用户 fg 时，就再把 Vim 设置成前台进程，并给它一个 SIGCONT 让它继续就好了。

最终的成品 vimtrace 在这里。我的 zsh 配置是这样子的：

if (( $+commands[vimtrace] )); then
  (( $+commands[strace] )) && alias strace='vimtrace strace'
  (( $+commands[ltrace] )) && alias ltrace='vimtrace ltrace'
else
  (( $+commands[strace] )) && strace () { (command strace "$@" 3>&1 1>&2 2>&3) | vim -R - }
  (( $+commands[ltrace] )) && ltrace () { (command ltrace "$@" 3>&1 1>&2 2>&3) | vim -R - }
fi

后记：

strace 有时候还是会改变进程的行为的。这种时候更适合用 sysdig。Arch 刚刚更新的 sysdig 版本已经修正了崩溃的问题了～不过 Vim 对 sysdig 的输出就不像 strace 那样有好看的语法着色了。

其实我当时用 systemtap 来看信号发送情况更方便一些。不过那个需要内核调试符号，几百M的东西，装起来累啊……