From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8403 invoked from network); 29 Jun 1999 12:08:03 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Jun 1999 12:08:02 -0000 Received: (qmail 20356 invoked by alias); 29 Jun 1999 12:07:33 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6919 Received: (qmail 20349 invoked from network); 29 Jun 1999 12:07:33 -0000 Date: Tue, 29 Jun 1999 14:07:32 +0200 (MET DST) Message-Id: <199906291207.OAA21233@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Tue, 29 Jun 1999 15:58:36 +0400 Subject: RE: PATCH: that execution stuff Andrej Borsenkow wrote: > > 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?). Uff. That feels good ;-) And, yes, the two ^C's are expected -- one for the gzcat which doesn't give us any information and the second one to kill the sub-shell. If the first gzcat in the loop has finished you need only one -- the second 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. Extremly hard. To be exact: almost impossible because we might have a list that first defines a function and then calls a command that once looked like an external command but after that definition calls the function. And other nasty things like that. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de