From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29660 invoked from network); 13 Dec 1999 17:42:35 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 13 Dec 1999 17:42:35 -0000 Received: (qmail 11769 invoked by alias); 13 Dec 1999 17:42:27 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9022 Received: (qmail 11762 invoked from network); 13 Dec 1999 17:42:25 -0000 From: "Bart Schaefer" Message-Id: <991213174221.ZM11624@candle.brasslantern.com> Date: Mon, 13 Dec 1999 17:42:21 +0000 In-Reply-To: Comments: In reply to Zefram "Re: PATCH (and another bug report): Re: zsh script and SIGCONT" (Dec 13, 10:25am) References: <199912131100.MAA23892@beta.informatik.hu-berlin.de> In-Reply-To: <199912131100.MAA23892@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: PATCH (and another bug report): Re: zsh script and SIGCONT" (Dec 13, 12:00pm) X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-workers@sunsite.auc.dk Subject: Re: PATCH (and another bug report): Re: zsh script and SIGCONT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 13, 10:25am, Zefram wrote: } 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. } } They can't. A while loop requested in the current shell *can't* be } backgrounded after being started, any more than you could background } a builtin. Have you tried it lately? The conclusion we reached was that if you explicitly suspend the loop, you accept the same consequences as if you backgrounded it in the first place. (Just as if you interrupted it with ^C.) This was intended to apply only to interactive shells (and now it does). } The loop has to be able to affect shell variables and so } on, which means it has to execute in the shell process. That, is probably the reason for this: On Dec 13, 12:00pm, Sven Wischnowsky wrote: } } 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. I can see where one should reasonably assume that a script read with `.' is specifically intended to modify the state of the current shell, and therefore should never be forked off once it has started. (This begs the question of whether ". script &" is ever reasonable, but we can't do anything about that.) So I was about to suggest that we should simply turn off MONITOR during `.' and `source', since it's rather bizarre to have the loop keep going leaving behind a trail of suspended jobs until the job table fills. But then I tried in in bash -- where the lack of NOTIFY means that you don't even find out about the string of suspended jobs until the loop exits -- and now I'm not so sure. -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com