Zsh Mailing List Archive
Messages sorted by:
Re: Change in suspend behavior
- X-seq: zsh-users 3875
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: "Sullivan N. Beck" <sbeck@xxxxxxxxxxxx>, zsh-users@xxxxxxxxxxxxxx
- Subject: Re: Change in suspend behavior
- Date: Thu, 10 May 2001 15:35:13 -0700
- In-reply-to: <20010510195228.018E6DCC4@xxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- References: <20010510195228.018E6DCC4@xxxxxxxxxxxxxxxxx>
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).
Messages sorted by: