Date: Thu, 12 Feb 1998 04:05:41 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, cracauer@cons.org Cc: freebsd-current@FreeBSD.ORG Subject: Re: cvs commit: src/bin/sh jobs.c Message-ID: <199802111705.EAA04905@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >> (c) #!/bin/sh >> >> (while :; do catchint; done) >> >> >> >> Now there is a subshell. It must be killed by SIGINT. (?) >> > >> >For me (our sh and bash), the whole script (outer shell, inner shell, >> >catchint) is terminated on SIGINT. It's the way it should be, IMHO. >> >> Actually, it doesn't for your version of sh, or bash. At least for >> your version of sh, the subshell waits for catchint, and then doesn't >> exit because catchint exits with a normal status. > >There must be some misunderstanding here. > >If catchint is a program with SIGINT => SIGN_DFL, all versions of sh >(original, your, mine, bash) exit this script (test10.sh from >testsuite) immedeatly: It's not. It's a program that catches SIGINT and exits normally (i.e., with a non-signal status) in its SIGINT handler. >#!./testshell >echo 'You should be able to end the script with one SIGINT' >(while :; do wc /kernel > /dev/null ; done) wc doesn't catch SIGINT. >The first SIGINT kills wc, the inner shell and the outer shell. Not quite. The first SIGINT kills wc, but is ignored by both shells (probably incorrectly by at least the inner shell). Then the inner shell notices that wc was killed with a SIGINT and relays this SIGINT to itself by killing itself with a SIGINT. This kills it completely because it is no longer ignoring SIGINT. Then the outer shell notices that the inner shell was killed by a SIGINT and relays the SIGINT to itself, etc. Relaying is not done for signals other than SIGINT, so test10.sh can't be killed by SIGQUIT with your version of sh. >If you mean catchint to be a program that directs SIGINT to its own >routine and not exit on it, then you're right, this loop isn't >breakable by SIGINT if the shell behaves the way I think is right. Yes, if the shell behaves the way I think is wrong. >If an application catches SIGINT for its own purposes (i.e. emacs), >then - in my opinion - the surrounding shellscript should not behave >different when a) the catchint program ends without using SIGINT and >b) the catchint program ends and has used SIGINT while it was running. If a program wants to use SIGINT, then it should avoid sending it to the entire process group. This prevents it from using SIGINTs generated by the tty. >This is the only way to ensure that an application we can assure that >system(2) does what the application writer expects if he/she calls it >with $EDITOR. Hmm. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199802111705.EAA04905>