cc: wan_jm at 126.com
Subject: Re: Re: [ksh93-integration-discuss] how does ksh deals "CTRL+C",
difficult to understanding.
--------
> Hello David Korn:
> thanks for your answers.
> but it is still not clear to me now.
>
>
> 1. you said with job control(the ksh I am using in Solaris 10 now should
> be t
> he one with job control, right?), a.out program runs in a separate process
> group
> . but from the result:
> -bash-3.00>$ps -ef | grep a.out
> wanjm 8384 8383 0 09:43:31 pts/2 0:00 ./a.out
> wanjm 8386 7257 0 09:43:36 pts/3 0:00 grep a.out
> -bash-3.00>$ps -j -p 8384
> PID PGID SID TTY TIME CMD
> 8384 8383 7250 pts/2 0:00 a.out
> -bash-3.00>$ptree 8384
> 377 /usr/lib/inet/inetd start
> 7247 /usr/sbin/in.telnetd
> 7250 -bash
> [i] 8383 /usr/bin/ksh ./sigint.sh[/i]
> 8384 ./a.out
> -bash-3.00>$ps -j -p 8383
> PID PGID SID TTY TIME CMD
> 8383 8383 7250 pts/2 0:00 sigint.sh
>
> it seems that both sigint.sh(/usr/bin/ksh ./sigint.sh) & a.out are in the
> same p
> rocess gourp(PGID 8383).
I had misread your message. I thought that you had run a.out from an
interactive ksh with a trap on INT set at the shell level.
If you run a script, and the script runs an a.out, they both run in
the same process group so that the information I sent you does not
apply. The INT signal gets sent to both processes.
However, I ran the program you sent, and in all cases I got the end
to output and the program ended normally. The input y and Y produced
the same results. What version of ksh93 are you running?
>
>
> 2. how does shell know the shell know the program is termited with SIGINT or
> QUI
> T from exit value.
When a process terminates with a signal, the lower order 8 bits if
the exits status returned by wait() contain the signal number.
Otherwise the lower 8 bits are 0 and the upper
bits contain the exit status.
>
> 3. int your answer there is "The standard says that an interrupt handler for
> INT
> that exits should first unset the signal handler and then send itself the
> INT s
> ignal after doing the cleanup."
> how to realize this, could you please give an small example?
What you do in the signal handler, is
signal(sig,SIG_DFL);
sigrelease(sig);
kill(getpid(),sig);
pause();
This
1. resets the signal to the default.
2. unblocks the signal which could be blocked by the call to the handler.
3. Sends the signal to the process.
4. Waits for the signal to be received so that the process terminates
by the signal.
If the parent is an interactive shell in another process group, this
will cause the ^C to be propogated.
>
> thanks.
> --
>
David Korn
dgk at research.att.com
