Change in suspend behavior

Change in suspend behavior

[Sullivan N. Beck]

Using zsh-3.1.5, I would often make use of a feature of zsh.  I would do
the following:

  % 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 which I was able to toggle back and forth using
job control commands.  Since zsh offers the wonderful feature of
autoloaded functions, I was able to wrote scripts which work with the
job table and do some pretty neat stuff with this feature (for example,
if mycmd is slogin, I was able to get most of the functionality of the
screens command).

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.  The only way to run the "mycmd bar"
command is to foreground the loop and kill/exit the "mycmd foo".

This seems very bizarre to me (is zsh creating a sub-shell now every
time it makes a loop?), and it definitely less useful to me.  Is there
a config variable I can set to get the original behavior back?

Thanks for any information.


--------------------------|  Sullivan Beck  |---------------------------
mailto:sbeck@cise.ufl.edu          |            Senior System Programmer
http://www.cise.ufl.edu/~sbeck     |               University of Florida
PH : (352) 392-1057                |                     CISE Department
Fax: (352) 392-1220                |                            CSE 314E
                                   |         Gainesville, FL  32611-6120
------------------------------------------------------------------------

Re: Change in suspend behavior

[Bart Schaefer]

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