为什么这些代码在各种发行版/ Unix中表现不同？

Question

以下(一个小的C程序和一个调用它的python脚本)在各种Unix上表现不同.

在其中一些(例如Debian stable)中,C app获取信号,消息从信号处理程序打印得很好并且脚本完成.在其他人(例如,两年前的Ubuntu和OpenBSD)中,信号丢失,因此根本不打印消息,并且脚本永远等待...

信号总是传递,如果在python脚本中,我改变了这个......

mysub=subprocess.Popen("./cryInAbort", shell=True)

进入这...

mysub=subprocess.Popen("./cryInAbort", shell=False)

所以看起来在某些Unix中,中间shell"吃掉"SIGINT,而在其他Unix中,它将它转发给子进程(C程序).

我注意只在信号处理程序中调用重入函数,所以这似乎与我的C代码无关 - 它看起来好像是在"/ bin/sh"中的信号处理行为(Python使用的默认shell)产生的东西)在Unix上并不"稳定"......

难道我做错了什么？

编辑:如果你想知道为什么我使用"shell = True":这是因为在我的真实代码中,我不只是传递"./executable" - 我使用shell代码进行循环和通配符.

这是在获得SIGINT时打印和死亡的C代码:

#include <signal.h>
#include <unistd.h>

void my_handler()
{
    static const char msg[] = "Goodbye - test was OK.\n";
    write(1,msg,sizeof(msg));
    fsync(1);
    _exit (0);
}

int main()
{
    (void) signal (SIGINT, my_handler);
    while (1);
}

这是通过发送SIGINT来测试它的Python脚本:

#!/usr/bin/env python
import subprocess,signal,time
mysub=subprocess.Popen("./cryInAbort", shell=True)
time.sleep(2)
mysub.send_signal(signal.SIGINT)
mysub.wait()

Answer 1

仅仅因为Python使用/bin/sh并不意味着它在所有系统上都是相同的shell.

/bin/sh 几乎总是象征性链接形式的别名:真正的shell可能是busybox,bash,ash,csh,ksh,dash,zsh,tcsh或者疯狂的东西(呃).

确认您实际上在所有系统上使用相同的shell,然后如果问题是特定的shell,您知道在哪里查找有关它的行为的更多信息.