From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17118 invoked from network); 17 Jun 1999 09:23:31 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 17 Jun 1999 09:23:31 -0000 Received: (qmail 1990 invoked by alias); 17 Jun 1999 09:23:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6690 Received: (qmail 1982 invoked from network); 17 Jun 1999 09:23:17 -0000 Date: Thu, 17 Jun 1999 11:23:16 +0200 (MET DST) Message-Id: <199906170923.LAA09259@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Wed, 16 Jun 1999 17:16:01 +0000 Subject: Re: pws-22: killing the ZSH loops problem Bart Schaefer wrote: > 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. I think, this is the way to go. I'll have a look at it, but probably not before the weekend. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de