要说哪个 shell 最复杂难学，我肯定回答 zsh。而要说哪个 shell bug 最多，毫无疑问是 bash 了。shellshock 这种大家都知道的我就不说了。bash 有很多很诡异的角落，昨天我亲身碰到一个。
我有一个 Python 程序 A，会使用 subprocess 带 shell=True 跑一行 shell 命令。那条命令会在后台跑另外一个 Python 程序 B。诡异的事情是，当我向 B 的进程发送 SIGINT 时，无法结束它，以及它下边带的一个 tail 进程。一开始我还没注意到 B 的进程本身没有被 SIGINT 杀死，是在无效的情况下被 A 用 SIGKILL 杀死的。我只看到那个 tail 程序还活着。所以我去处理了一下 KeyboardInterrupted 异常，来结束掉那个 tail。
结果很诡异：KeyboardInterrupted 异常并没有发生。通过 strace 观察可以看到，B 进程在读 tail 的输出，然后收到了 SIGINT，然后接着读 tail 的输出……我一开始还以为这个和 PEP 475 相关，以为是 Python 自动重启了被中断的系统调用，所以没来得及处理信号（Python 的信号并不是及时处理的）。然后就去仔细看文档。结果文档告诉我，如果注册了信号处理函数，并且它抛出异常的话，那么被中断的系统调用是不会被重试的。所以这就不对了。
然后我又测试了直接在终端运行 B，而不是通过 A 去运行。本来我开发的时候就是这么测试它的，也没遇到什么怪异的现象。结果确实没有什么怪异的事情发生：即使我使用 kill 命令只给 B 发送 SIGINT 信号，Python 的 KeyboardInterrupted 逻辑会被触发，然后它主动杀掉 tail 进程。（使用 Ctrl-C 的话，B 和 tail 都会收到 SIGINT 信号的。）
疑惑的时候，我又想到了拿 SIGINT 去杀那个不死的 tail 进程，这才发现它也出现奇怪的行为了：正在读 inotify 的文件描述符呢，来了个 SIGINT 信号，然后它接着读 inotify 去了……跟 B 出现的问题一样。我又去查了 tail.c 的源码，也没发现它对 SIGINT 有特殊的处理啊。
难道是继承过来的？man 7 signal 了一下，果然：
During an execve(2), the dispositions of handled signals are reset to the default; the dispositions of ignored signals are left unchanged.
所以 tail 和 B 继承了一个「忽略 SIGINT」的行为。（nohup 就是用的类似的手段啊。）
于是 strace -f 了整个从 A 开始的进程树，最后发现这问题和 Python 并没有什么关系，而是 bash 的错！
A 是用 shell=True 调用的命令，所以它调用了 /bin/sh。系统是 CentOS，所以 /bin/sh 是指向 bash 的。所以这里实际上调用了 bash，而它的处理有问题。
要重现这个 bug 很容易：
bash -c 'sleep 1000 &'
然后这个 sleep 进程就会忽略 SIGINT 和 SIGQUIT 了。我也不明白 bash 这是想要做什么。
之前也遇到过另外几个 bash 的 bug（或者是 feature？）——
-
在终端中，在脚本中执行交互式 bash 时，第一个 bash 进程会将自己设为前台进程组，导致后来的进程收到 SIGTTIN 或者 SIGTTOU。很神奇，两行同样的命令，第一条和后边的行为不一致。
-
在 bash 中，执行不带 shebang 的 shell 脚本时，脚本会在当前 bash 进程内执行，造成 history 命令的行为异常。
-
这个是听说的。输出失败时，未写入目标的内容仍留在缓冲区内，会在奇怪的地方冒出来。
以后还是尽量避开 bash 吧。有 zsh 用 zsh，有 dash 用 dash；它们都没有本文提到的这些问题。
