From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3) with ESMTP id CAA18028 for ; Wed, 17 Apr 1996 02:06:43 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id LAA20973; Tue, 16 Apr 1996 11:57:13 -0400 (EDT) Resent-Date: Tue, 16 Apr 1996 11:57:13 -0400 (EDT) Message-Id: <199604161556.RAA02778@hydra.ifh.de> To: zsh-workers@math.gatech.edu Subject: Re: signal handling bug In-reply-to: "hzoli@cs.elte.hu"'s message of "Sun, 31 Mar 1996 20:14:17 MET." <199603311814.UAA00723@hzoli.ppp.cs.elte.hu> Date: Tue, 16 Apr 1996 17:56:55 +0200 From: Peter Stephenson Resent-Message-ID: <"dewAK2.0.d75.PDySn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/929 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu hzoli@cs.elte.hu wrote: > % zsh -c 'trap "echo Interrupt ; exit" INT ; while true ; do sleep 1 ; done' > > After applying the patches, this is interruptible, but the trap is not > executed (and it is interruptible even if I use trap - INT). I was about to report failure when I had an idea (pity this doesn't happen very often) and I've managed to fix the first half of the problem, so what Robert the Bruce said is probably right. The problem was the test for whether the job that just ran was in the foreground: it was relying on the job handling code, so didn't work in a non-interactive shell. I've separated the job handling part out and set `inforeground' in updatestatus() simply according to whether we are using the status of the current job to update the global status variable, which sounds pretty plausible to me. inforeground is later tested to see if the trap should be run. This doesn't fix the other half of the problem, that the job is interruptible when supposedly ignoring SIGINT. That's certainly a separate problem, possibly beyond my signal knowledge (meaning of course ``knowledge of signals'', rather than ``notable knowledge''), but I'll probably take a look at it anyway. Point to note: ksh M-11/16/88f (the most widespread version of ksh '88) has the same problem --- the problem reported by Zoltan after the previous set of patches, that is --- so we should feel either smug or uneasy. This patch is intended to go on top of all the other trap patches, of course. I don't know whether or not it actually needs them, but it's pointless to use it without the others. *** Src/jobs.c.spec Mon Apr 15 11:45:03 1996 --- Src/jobs.c Tue Apr 16 17:36:50 1996 *************** *** 123,140 **** return; } else { /* job is done, so remember return value */ lastval2 = val; ! /* If last process was run in the currrent shell, keep old status */ ! if (job == thisjob && !(jn->stat & STAT_CURSH)) ! lastval = val; } pgrp = gettygrp(); /* get process group of tty */ ! /* is this job in the foreground */ ! if (jn->gleader == pgrp || (pgrp > 1 && kill(-pgrp, 0) == -1)) ! inforeground = 1; ! ! if (inforeground && !ttyfrozen && !val && !jn->stty_in_env) gettyinfo(&shttyinfo); adjustwinsize(); /* check window size and adjust if necessary */ if (somestopped && jn->stat & STAT_SUPERJOB) --- 123,142 ---- return; } else { /* job is done, so remember return value */ lastval2 = val; ! /* If last process was run in the current shell, keep old status ! * and let it handle its own traps ! */ ! if (job == thisjob && !(jn->stat & STAT_CURSH)) { ! lastval = val; ! inforeground = 1; ! } } pgrp = gettygrp(); /* get process group of tty */ ! /* is this job in the foreground of an interactive shell? */ ! if ((jn->gleader == pgrp || (pgrp > 1 && kill(-pgrp, 0) == -1)) && ! !ttyfrozen && !val && !jn->stty_in_env) gettyinfo(&shttyinfo); adjustwinsize(); /* check window size and adjust if necessary */ if (somestopped && jn->stat & STAT_SUPERJOB) -- Peter Stephenson Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77330 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany.