在写一个 minishell 的时候，需要捕捉从键盘输入的 ctrl+c 产生的 SIGINT 信号，转入自己的处理函数，代码大致如下

#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <signal.h>

int shell_loop() {
    setup();
    COMBINE_COMMAND cmd;
    while (1) {
        init_cmd(&cmd);
        if (read_cmd(&cmd) == -1) {
            break;
        }
        if (strlen(cmd.cmd_line) == 0) {
            clean_up_cmd(&cmd);
            continue;
        }
        parse_cmd(&cmd);
        // print_cmd(&cmd);
        execute_cmd(&cmd);
        clean_up_cmd(&cmd);
    }
    return 0;
}

void setup() {
    signal(SIGINT, sigint_handler);
    signal(SIGQUIT, SIG_IGN);
}

void sigint_handler(int sig) {
    printf("\n[minishell]$ ");
    fflush(stdout);
}

在 make 编译的时候没有问题，但是调试执行的时候结果一直不对，按下 ctrl+c 之后依然退出了程序，怎么调试都不行，于是索性单独新建了一个文件夹，在里面写了一份测试代码

#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

void init2();
void handler(int sig);

int main() {
    signal(SIGINT, handler);
    char line[1024];
    while (fgets(line, 1024, stdin) != NULL) {
        init2();
    }
    return 0;
}

void init2() {
    printf("hello");
    fflush(stdout);
}

void handler(int sig) {
    init2();
}

然后编译执行

zrj@vm:~/c/test$ gcc main.c 
zrj@vm:~/c/test$ ./a.out 

hello
hello
hello^Chello^Chello^Chello
hello
hello
hellozrj@vm:~/c/test$ 

发现是没有任何问题的，一切都按照预期的方式去跑，于是回头去看原来的代码，但是怎么对比都没有发现哪里出问题，到最后几乎要把原来的代码都差不多注视光了，还是没有找到问题所在，这个时候突然想起 Makefile 来，于是看回原来工程的 Makefile，是这样的

.PHONY:clean
CC=gcc
CFLAGS=-Wall -g -std=c99
BIN=minishell
OBJS=main.o str.o shell.o
$(BIN):$(OBJS)
	$(CC) $(CFLAGS) $^ -o $@
%.o:%.c
	$(CC) $(CFLAGS) -c $< -o $@
clean:
	rm -f *.o $(BIN)

注意到第三行的编译参数中有使用了 c99，于是尝试去掉这个东西，再次编译，报一些语法错，主要是用到这个语法，

for (int i=0; i<count; i++)

，把这些文件暂时从 Makefile 中去掉，再编译，能够通过，再执行，于是就发现没有问题了，信号能够正常的捕捉并处理，于是知道是 c99 的问题

google 搜了一下，找到这里，http://forums.debian.net/viewt…

I continue my monologue. Thanks for listening.The solution to my problem seems to be simply the following:

Executive summary: use -std=gnu99 on linux if you need some C99 functions (e.g. strtof) but also want to use functions like sigaction and strtok_r

gcc on linux is stricter than gcc on FreeBSD (or icc on either FreeBSD or linux) concerning standards.
gcc -std=c99 on linux means: *only* recognize functions specified in the standard (no sigaction, no strtok_r etc)
gcc -std=c99 on FreeBSD or icc -std=c99 on either FreeBSD or linux means recognize functions specified in the standard. This corresponds more or less to -std=gnu99 on linux

PS. This trap seems to be quite common (e.g. discussions on debian-glibc about the “fact” that strtof is completely broken on linux). I would be grateful if somebody could point me to a good overview describing what standards compliance means for various OS/compiler+options/standards combinations.

于是把 c99 改成 gnu99 ，问题得到解决

另外这里也有讨论，http://stackoverflow.com/quest…

Use sigaction(2) rather than signal(2).

The Linux man page has this, in particular, in the Portability section:

In the original UNIX systems, when a handler that was established using signal() was invoked by the delivery of a signal, the disposition of the signal would be reset to SIG_DFL, and the system did not block delivery of further instances of the signal. System V also provides these semantics for signal(). This was bad because the signal might be delivered again before the handler had a chance to reestablish itself. Furthermore, rapid deliveries of the same signal could result in recursive invocations of the handler.

BSD improved on this situation by changing the semantics of signal handling (but, unfortunately, silently changed the semantics when establishing a handler with signal()). On BSD, when a signal handler is invoked, the signal disposition is not reset, and further instances of the signal are blocked from being delivered while the handler is executing.

The situation on Linux is as follows:

The kernel’s signal() system call provides System V semantics.

By default, in glibc 2 and later, the signal() wrapper function does not invoke the kernel system call. Instead, it calls sigaction(2) using flags that supply BSD semantics. This default behav‐ ior is provided as long as the _BSD_SOURCE feature test macro is defined. By default, _BSD_SOURCE is defined; it is also implicitly defined if one defines _GNU_SOURCE, and can of course be explic‐ itly defined.
On glibc 2 and later, if the _BSD_SOURCE feature test macro is not defined, then signal() provides System V semantics. (The default implicit definition of _BSD_SOURCE is not provided if one invokes gcc(1) in one of its standard modes (-std=xxx or -ansi) or defines various other feature test macros such as _POSIX_SOURCE, _XOPEN_SOURCE, or _SVID_SOURCE; see feature_test_macros(7).)

Using std=gnu99, you’re getting BSD semantics. Using -std=c99, you’re getting System V semantics. So the signal handler is “reinstalled” in one case (BSD), and the signal disposition is reset back to SIG_DFL in the other (System V).