From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14598 invoked from network); 21 Jun 1999 07:10:13 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 21 Jun 1999 07:10:13 -0000 Received: (qmail 16731 invoked by alias); 21 Jun 1999 07:09:30 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6733 Received: (qmail 16724 invoked from network); 21 Jun 1999 07:09:29 -0000 From: "Andrej Borsenkow" To: "Bart Schaefer" , Subject: RE: pws-22: killing the ZSH loops problem Date: Mon, 21 Jun 1999 11:08:50 +0400 Message-ID: <000201bebbb4$e9f3a9c0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) Importance: Normal In-Reply-To: <990618164443.ZM8127@candle.brasslantern.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > } > } We need it only if MONITOR is set > > Not true! MONITOR only affects handling of ^Z, not of ^C. We need to be > able to properly interrupt such loops in any shell. > Ahem ... yes. What about "only in interactive shells?" > However, we only need it when (a) there's at least one external command > (you can already interrupt purely builtin loops, try it) and (b) that > external command doesn't return the proper exit status for zsh to learn > that it caught a signal. We can't know (b) in advance, so I can't come > up with anything useful for (a) except to fork twice on every external > command, which is horribly wasteful. > If don't miss something again: we have to fork only for the loop as whole. In other words, only if the command being executed (top-level command) is a complex command. This means, that in following while xxx while yyy done done we only fork once for the outer loop and only, if it was input to PS1. It means, we don't need to fork for the loops in functions (because theay are *not* zsh commands), so, it seems, execution time penalty is acceptable. After all, you don't use loops on every prompt. > } And it just occured to me - is it possible to kill/stop/resume shell > } function? > > Yes. In fact, that was the recommended workaround for several pipe-into- > a-loop problems before they gradually got fixed: Well, thanks for reminder. Still, I'd really prefer properly running loops :-) /andrej