From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12026 invoked from network); 18 Jun 1999 15:39:14 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jun 1999 15:39:14 -0000 Received: (qmail 13887 invoked by alias); 18 Jun 1999 15:39:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6719 Received: (qmail 13880 invoked from network); 18 Jun 1999 15:39:01 -0000 From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: pws-22: killing the ZSH loops problem Date: Fri, 18 Jun 1999 19:33:18 +0400 Message-ID: <000a01beb99f$e3c28fb0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <199906180855.KAA12796@beta.informatik.hu-berlin.de> > > (Btw. `foo | while ...' can be ^C'ed because we have the `foo' to find > that out. This means that we could make normal loops be ^C'able by > forking of a sub-shell for every loop and let the sub-shell do > nothing. Then ^C would SIGINT the sub-shell and the parent shell would > be notified about this -- but this is really ugly isn't it? Or should > we? But that would be an extra fork on every shell construct...) > We need it only if MONITOR is set and this is typically (if not exclusively) interactive shells. Unfortunately, with new completion, we use loops heavily. OTOH exactly with new completion in mind, there must be some way to kill it. It is not good, when completion function hangs in some loop without any possibility to get out. And it just occured to me - is it possible to kill/stop/resume shell function? > And another `btw.': comparison with bash shows that it has the same > problem ^C'ing such commands in loops and behaves like zsh. But it > can't even correctly stop such loops. > > I looked at how it is implemented in ksh and csh on our system. csh: resets process group for every external command. It is impossible to ^C loop (for the same reason as in Zsh). It is possible to ^Z it - but it makes loop disapper. After fg only the last started external command is brought in foreground. When it exits, loop effectively terminates. Looks horribly broken. ksh: does not reset process group at all. Ignores ^Z (TSTP). It is possible to ^C loop (ksh cathes INT). It is impossible to ^Z loop because TSTP remains ignored by child (I suspect actually a bug in ksh - it should reset TSTP to default before exec'ing) So - assuming, that we won't reset process group - is it possible to make zsh catch INT (QUIT?) and TSTP and behave nicely? /andrej