Re: pws-22: killing the ZSH loops problem

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On Jun 16,  5:14pm, Peter Stephenson wrote:
} Subject: Re: pws-22: killing the ZSH loops problem
}
} "Andrej Borsenkow" wrote:
} > bor@itsrm2:~%> while true
} > while> do
} > while> echo $((i++))
} > while> sh -c "read line"
} > while> done
} > 0
} > ^C
} > 1
} > ^C
} > 2
} 
} 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.

Yes, I believe this is correct.  It's related to this comment in jobs.c:
    /* When MONITOR is set, the foreground process runs in a different *
     * process group from the shell, so the shell will not receive     *
     * terminal signals, therefore we we pretend that the shell got    *
     * the signal too.                                                 */

If the foreground job catches INT and doesn't exit with the proper status,
zsh can't tell anything other than that it exited -- just as Andrej found
by experiment.

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

One possibility is to not permit job control of individual external jobs
run within a shell construct; that is, force ^Z to stop the entire shell
loop and restart it.  As has been mentioned before, this is easy in other
shells because they typically fork off the tails of pipelines whereas zsh
always forks off the heads -- but some of the new list_pipe code that was
added recently may give us the necessary hooks to manage it.  Given that,
we can stop using new pgrps for subjobs of a shell construct, and then
zsh can get the terminal signals directly again.

Unfortunately this might require shoveling around some bits of context
information that aren't presently available, in order to prevent the
execution code from creating the new process group.  I haven't looked.

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