From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6463 invoked from network); 16 Jun 1999 15:43:07 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Jun 1999 15:43:07 -0000 Received: (qmail 2444 invoked by alias); 16 Jun 1999 15:43:01 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6676 Received: (qmail 2437 invoked from network); 16 Jun 1999 15:42:59 -0000 Message-Id: <9906161514.AA26937@ibmth.df.unipi.it> To: "ZSH workers mailing list" Subject: Re: pws-22: killing the ZSH loops problem In-Reply-To: ""Andrej Borsenkow""'s message of "Tue, 15 Jun 1999 20:45:04 DFT." <001901beb74e$6b1dcdc0$21c9ca95@mow.siemens.ru> Date: Wed, 16 Jun 1999 17:14:19 +0200 From: Peter Stephenson "Andrej Borsenkow" wrote: > bor@itsrm2:~%> while true > while> do > while> echo $((i++)) > while> sh -c "read line" > while> done > 0 > ^C > 1 > ^C > 2 I've formed a hypothesis based on different versions of ksh. On some versions, the `sh -c' goes into a different process group: here, I get the same problem as zsh. On others, the process group of the sh is the same as that of the ksh: then the loop exits cleanly. 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. 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. I haven't quite understood why a zsh in the loop works properly (i.e. the loop exits cleanly when interrupted), but it seems to be nothing to do with process groups: the `zsh -c' is exiting with the correct status (i.e. WIFSIGNALED(...) returns true so the parent shell know what happened). Looks like we got something right. Arguably we can blame the problem on all those shells which don't do this :-). (Next we find it's only because of a bug that zsh works this way...) -- Peter Stephenson Tel: +39 050 844536 WWW: http://www.ifh.de/~pws/ Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy