From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14824 invoked from network); 10 May 2001 22:36:10 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 10 May 2001 22:36:10 -0000 Received: (qmail 14062 invoked by alias); 10 May 2001 22:35:56 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 3875 Received: (qmail 14044 invoked from network); 10 May 2001 22:35:55 -0000 From: "Bart Schaefer" Message-Id: <010510153513.ZM24266@candle.brasslantern.com> Date: Thu, 10 May 2001 15:35:13 -0700 In-Reply-To: <20010510195228.018E6DCC4@mail.cise.ufl.edu> Comments: In reply to "Sullivan N. Beck" "Change in suspend behavior" (May 10, 3:52pm) References: <20010510195228.018E6DCC4@mail.cise.ufl.edu> X-Mailer: Z-Mail Lite (5.0.0 30July97) To: "Sullivan N. Beck" , zsh-users@sunsite.auc.dk Subject: Re: Change in suspend behavior MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On May 10, 3:52pm, Sullivan N. Beck wrote: > Subject: Change in suspend behavior > > Using zsh-3.1.5, I would often make use of a feature of zsh. Strictly speaking, you would abuse a bug in zsh, I'm afraid. > % for i in foo bar ;do > for> mycmd $i > for> done > > Then, once "mycmd foo" was running, I could suspend that job with > 'Ctrl-z', proceed to start up "mycmd bar" and then I would end up with > two backgrounded jobs You should be able to get the same effect by doing for i in bar foo; do mycmd $i & done; wait; fg The "wait" is just there to be sure that all the jobs have a chance to start up (and then stop again on SIGTTOU or SIGTTIN) before the "fg" is executed. If "mycmd" is something that will actually run in the background, add a "kill -TSTP $! ;" between the ampersand and "done". > I unpgraded to zsh-3.1.9 (and I also tried zsh-4.0.1-pre4, but the > behavior is the same there), and instead of suspending "mycmd", it > suspends the entire for loop. It also interrupts the entire for-loop if you type control-C; not doing so was the real bug -- before, a loop like for i; do something safe; something dangerous; done would immediately execute something dangerous if something safe were interrupted or suspended. There was no reliable way to break out of a loop once it was running. Deterministic behavior is preferable, even if inconvenient for special cases. > This seems very bizarre to me (is zsh creating a sub-shell now every > time it makes a loop?) No, it waits until it actually receives the SIGTSTP and then forks off the loop (or the entire shell function if the loop is in a function body). If you never signal it, it behaves as it always did. > Is there a config variable I can set to get the original behavior back? No, sorry (I'm sympathetic, but not apologetic).