From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12763 invoked from network); 18 Jun 1999 16:45:44 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 18 Jun 1999 16:45:44 -0000 Received: (qmail 18584 invoked by alias); 18 Jun 1999 16:45:35 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6720 Received: (qmail 18577 invoked from network); 18 Jun 1999 16:45:33 -0000 From: "Bart Schaefer" Message-Id: <990618164443.ZM8127@candle.brasslantern.com> Date: Fri, 18 Jun 1999 16:44:43 +0000 In-Reply-To: <199906180855.KAA12796@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: pws-22: killing the ZSH loops problem" (Jun 18, 10:55am) References: <199906180855.KAA12796@beta.informatik.hu-berlin.de> <000a01beb99f$e3c28fb0$21c9ca95@mow.siemens.ru> In-Reply-To: <000a01beb99f$e3c28fb0$21c9ca95@mow.siemens.ru> Comments: In reply to "Andrej Borsenkow" "RE: pws-22: killing the ZSH loops problem" (Jun 18, 7:33pm) X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: pws-22: killing the ZSH loops problem MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 18, 10:55am, Sven Wischnowsky wrote: } Subject: Re: pws-22: killing the ZSH loops problem } } Unless I'm missing something obvious, we can't simply execute } processes in a loop (or other shell construct) in the same pgrp as the } shell. Sure, this would give us the SIGINT, but it would also give us } the SIGSTOP -- suspending the shell. Strictly speaking, it would give us SIGTSTP -- ^Z does not generate STOP. Since TSTP is catchable (unlike STOP), the parent shell simply has to have a TSTP handler or ignore TSTP -- which zsh already does. Incidentally, and probably not strictly a zsh thing, `kill -STOP $$` in an xterm locks up the whole xterm (it won't even repaint itself or bring up the ctrl-buttonN menus) and closing the xterm with the window manager orphans the shell even if you've restarted it with `kill -CONT ...` from somewhere else. I had to `kill -9 ...` it. On Jun 18, 7:33pm, Andrej Borsenkow wrote: } Subject: RE: pws-22: killing the ZSH loops problem } } > (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 Not true! MONITOR only affects handling of ^Z, not of ^C. We need to be able to properly interrupt such loops in any shell. 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. } 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: Put the loop in a shell function and pipe to the function. That's still the best way to minimize the number of processes that get forked (there was a thread about this a while back, perhaps as much as a year ago). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com