Re: Change in suspend behavior

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

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).