Re: pws-22: killing the ZSH loops problem

["Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>]

On Jun 18, 10:55am, Sven Wischnowsky wrote:
} Subject: Re: pws-22: killing the ZSH loops problem
}
} Unless I'm missing something obvious, we can't simply execute
} processes in a loop (or other shell construct) in the same pgrp as the 
} shell. Sure, this would give us the SIGINT, but it would also give us
} the SIGSTOP -- suspending the shell.

Strictly speaking, it would give us SIGTSTP -- ^Z does not generate STOP.
Since TSTP is catchable (unlike STOP), the parent shell simply has to have
a TSTP handler or ignore TSTP -- which zsh already does.

Incidentally, and probably not strictly a zsh thing, `kill -STOP $$` in an
xterm locks up the whole xterm (it won't even repaint itself or bring up
the ctrl-buttonN menus) and closing the xterm with the window manager
orphans the shell even if you've restarted it with `kill -CONT ...` from
somewhere else.  I had to `kill -9 ...` it.

On Jun 18,  7:33pm, Andrej Borsenkow wrote:
} Subject: RE: pws-22: killing the ZSH loops problem
}
} > (Btw. `foo | while ...' can be ^C'ed because we have the `foo' to find
} > that out. This means that we could make normal loops be ^C'able by
} > forking of a sub-shell for every loop and let the sub-shell do
} > nothing. Then ^C would SIGINT the sub-shell and the parent shell would
} > be notified about this -- but this is really ugly isn't it? Or should
} > we? But that would be an extra fork on every shell construct...)
} 
} We need it only if MONITOR is set

Not true!  MONITOR only affects handling of ^Z, not of ^C.  We need to be
able to properly interrupt such loops in any shell.

However, we only need it when (a) there's at least one external command
(you can already interrupt purely builtin loops, try it) and (b) that
external command doesn't return the proper exit status for zsh to learn
that it caught a signal.  We can't know (b) in advance, so I can't come
up with anything useful for (a) except to fork twice on every external
command, which is horribly wasteful.

} And it just occured to me - is it possible to kill/stop/resume shell
} function?

Yes.  In fact, that was the recommended workaround for several pipe-into-
a-loop problems before they gradually got fixed:  Put the loop in a shell
function and pipe to the function.  That's still the best way to minimize
the number of processes that get forked (there was a thread about this a
while back, perhaps as much as a year ago).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com