Re: pws-22: killing the ZSH loops problem

[Peter Stephenson <pws@ibmth.df.unipi.it>]

"Andrej Borsenkow" wrote:
> bor@itsrm2:~%> while true
> while> do
> while> echo $((i++))
> while> sh -c "read line"
> while> done
> 0
> ^C
> 1
> ^C
> 2

I've formed a hypothesis based on different versions of ksh.

On some versions, the `sh -c' goes into a different process group: here, I
get the same problem as zsh.  On others, the process group of the sh is the
same as that of the ksh: then the loop exits cleanly.

So there are three cases (1) no job control, like sh, (2) job control and
the sh in the while loop goes into a different pgrp, (3) job control but
the sh in the while loop stays in the pgrp of the controlling shell.  Cases
(1) and (3) exit cleanly, because the shell itself gets the ^C; case (2),
which is what zsh is doing, doesn't because it doesn't.

So maybe zsh should not set a new process group for foreground processes
run within shell structures.  Sven, any ideas about doing this?  It might
clash with job control for such processes, which are currently handled by
forking the shell and setting its pgrp to that of the other jobs; this
wouldn't be possible any more, so we're going to have to live with
something not working.

I haven't quite understood why a zsh in the loop works properly (i.e. the
loop exits cleanly when interrupted), but it seems to be nothing to do with
process groups: the `zsh -c' is exiting with the correct status
(i.e. WIFSIGNALED(...) returns true so the parent shell know what
happened).  Looks like we got something right.  Arguably we can blame the
problem on all those shells which don't do this :-).  (Next we find it's
only because of a bug that zsh works this way...)

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy