From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7353 invoked from network); 16 Jun 1999 17:16:27 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Jun 1999 17:16:27 -0000 Received: (qmail 12378 invoked by alias); 16 Jun 1999 17:16:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6680 Received: (qmail 12371 invoked from network); 16 Jun 1999 17:16:10 -0000 From: "Bart Schaefer" Message-Id: <990616171601.ZM1681@candle.brasslantern.com> Date: Wed, 16 Jun 1999 17:16:01 +0000 In-Reply-To: <9906161514.AA26937@ibmth.df.unipi.it> Comments: In reply to Peter Stephenson "Re: pws-22: killing the ZSH loops problem" (Jun 16, 5:14pm) References: <9906161514.AA26937@ibmth.df.unipi.it> X-Mailer: Z-Mail (5.0.0 30July97) To: "ZSH workers mailing list" Subject: Re: pws-22: killing the ZSH loops problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 16, 5:14pm, Peter Stephenson wrote: } Subject: Re: pws-22: killing the ZSH loops problem } } "Andrej Borsenkow" wrote: } > bor@itsrm2:~%> while true } > while> do } > while> echo $((i++)) } > while> sh -c "read line" } > while> done } > 0 } > ^C } > 1 } > ^C } > 2 } } So there are three cases (1) no job control, like sh, (2) job control and } the sh in the while loop goes into a different pgrp, (3) job control but } the sh in the while loop stays in the pgrp of the controlling shell. Cases } (1) and (3) exit cleanly, because the shell itself gets the ^C; case (2), } which is what zsh is doing, doesn't because it doesn't. Yes, I believe this is correct. It's related to this comment in jobs.c: /* When MONITOR is set, the foreground process runs in a different * * process group from the shell, so the shell will not receive * * terminal signals, therefore we we pretend that the shell got * * the signal too. */ If the foreground job catches INT and doesn't exit with the proper status, zsh can't tell anything other than that it exited -- just as Andrej found by experiment. } So maybe zsh should not set a new process group for foreground processes } run within shell structures. Sven, any ideas about doing this? It might } clash with job control for such processes, which are currently handled by } forking the shell and setting its pgrp to that of the other jobs; this } wouldn't be possible any more, so we're going to have to live with } something not working. One possibility is to not permit job control of individual external jobs run within a shell construct; that is, force ^Z to stop the entire shell loop and restart it. As has been mentioned before, this is easy in other shells because they typically fork off the tails of pipelines whereas zsh always forks off the heads -- but some of the new list_pipe code that was added recently may give us the necessary hooks to manage it. Given that, we can stop using new pgrps for subjobs of a shell construct, and then zsh can get the terminal signals directly again. Unfortunately this might require shoveling around some bits of context information that aren't presently available, in order to prevent the execution code from creating the new process group. I haven't looked. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com