From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22099 invoked from network); 13 Dec 1999 11:00:12 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Dec 1999 11:00:12 -0000 Received: (qmail 24743 invoked by alias); 13 Dec 1999 11:00:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9012 Received: (qmail 24721 invoked from network); 13 Dec 1999 11:00:03 -0000 Date: Mon, 13 Dec 1999 12:00:01 +0100 (MET) Message-Id: <199912131100.MAA23892@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Sun, 12 Dec 1999 20:07:59 +0000 Subject: Re: PATCH (and another bug report): Re: zsh script and SIGCONT Bart Schaefer wrote: > ... > > Even worse than this ... if you read the script with ". p2", then ^Z only > stops the "sleep 1" and the loop keeps going. All three cases ought to > behave the same as executing the loop at the top-level prompt. > > I spent a while trying to trace through this, but it's nearly impossible > to use a debugger in combination with tty stop signals, and zsh's job > control is one of those places where "reading zsh source code makes you > go blind," as Tom Christiansen has said. Yes, real fun, isn't it... sigh. > I believe the script case has something to do with both zsh and sleep > getting the TSTP (which zsh doesn't have a special handler for); zsh forks > to background the entire while loop, and therefore the parent shell exits > from the loop -- but so does the forked child, for reasons that I can't > follow. > > However, in the case of a script, zsh doesn't need to do any of this; the > script can start and stop as its own process. Sounds reasonable. > So the following appears > to fix the script case, but I still don't know what's going on with ".". In line 725/726 in exec.c we explicitly turn the list_pipe handling off if we are sourcing. Removing these two lines makes it work in the way you (and I) expect it. However, this is an explicit test and since I don't have any idea why we did that, I won't produce a patch for it now. Mainly because I don't think I'll have the time today to find out why we added this test... if anyone has the time to look in the archive... Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de