cc: wan_jm at 126.com 
Subject: Re: [ksh93-integration-discuss] how does ksh deals "CTRL+C",  
difficult to understanding.
--------

> I wrote one program signal.c which catch CTRL+C.
> #include <signal.h>
> void
> abc(int abcd)
> {
>         char            a, b;
>         printf("are you sure to exit:\n");
>         scanf("%c%c", &a, &b);
>         if (a == 'y') {
>                 exit(0);
>         }
>         if (a == 'Y') {
>                 exit(1);
>         }
>         signal(SIGINT, abc);
> 
> }
> int main()
> {
>         signal(SIGINT, abc);
>         while (1) {
>                 sleep(1);
>         }
> }
> 
> and then wrote one shell program to call it. the shell also catches CTRL+C.
> #! /usr/bin/ksh
> trap "echo int" INT
> a()
> {
> ./a.out
> echo "a.out finished"
> }
> echo "begin"
> a
> echo "end"
> when I run the program and input ' Y ' to let a.out exit.
> then the shell also exit, there is no "end" output, it is really difficult to 
> un
> derstand why "end" was not output.
> when input ' y ', "end " is priented out.
> what is the reason that when input ' Y ', the shell stops works.
> -- 
> This message posted from opensolaris.org

You asked a good question and I will give you the answer.

First of all, with job control, your a.out program runs in a separate
process group so that the ^C signal is only sent to a.out, not
the ksh.

Before job control, a.out and ksh ran in the same process group and
both would get the signal which the shell would have held until
a.out exited and then it would have execute the trap.

However, the pre-job control shell had some undesirable side effects. 
For example, suppose I want to make edits to a bunch of files:

        for file in *.c
        do      vi $i
        done

If I were to hit ^C while editing one of the files the for loop would
terminate when this file was complete.

What the shell does is to look at the exit status of a.out.  If it
terminated with an exit status indicating that it terminated with INT
or QUIT, the shell sends itself this signal.

This difference in behavior was discussed in the POSIX.1 group
before the first issuance of the POSIX standard.  The standard
says that an interrupt handler for INT that exits should first
unset the signal handler and then send itself the INT signal
after doing the cleanup.

I proposed making an exit call from a signal handler causing the
exit status to be set to the signal sent to the handler, but this
was not accepted and the work was left to application writers.


David Korn
dgk at research.att.com

Reply via email to