From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8270 invoked from network); 29 Jun 1999 11:59:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Jun 1999 11:59:26 -0000 Received: (qmail 19579 invoked by alias); 29 Jun 1999 11:58:43 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6917 Received: (qmail 19572 invoked from network); 29 Jun 1999 11:58:43 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: PATCH: that execution stuff Date: Tue, 29 Jun 1999 15:58:36 +0400 Message-ID: <001201bec226$b7c9e400$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) In-Reply-To: <199906291051.MAA23127@beta.informatik.hu-berlin.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 > Andrej Borsenkow wrote: > > > > I don't need to point out that `while true; do gzip ...; done' is not > > > expected to be ^C'able again, do I? Maybe we should document this? > > > (Together with the ^Z/fg/^C-trick?) > > > > It does not work. I can suspend *and* kill 'while true; do gzcat > -f; done'. But > > after I suspend and resume it, I can neither kill nor suspend it again. > > Hm, it worked for me with `zcat ... >/dev/null'. But this patch might > also have an effect on this (because of this sub-shell-pgrp thing). > Yes, now it works as described. No way to kill loop with gzcat before ^Z; ant two ^C's after that (I forgot, are two ^C's expected? Or was it supposed to be only one?). In any case, as long as it is documented, it is far better as csh or ksh here. And thinking more about it - the only clean way to implement job control that works in any case is to start "guard zsh" for every pipeline (and run every pipeline in seperate process group). This is probably too much. It could be optimised if we are sure pipeline never executes external commands ... no idea how hard it is. /andrej