another 1.10 job control bug?

["Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>]

> i think the problem was when there are several processes in a group the
>leader isn't always the one that exits last, and then you could no longer
>signal the others from the terminal after that. (^c, ^z, ...)  of course
>you could say the parent should always catch SIGCHLD and then TIOCSPGRP
>whenever the first process in a pipe (for example) exited but somehow i
>doubt thats a real solution...  (although i did put such a hack in ksh
>first... :)

That is exactly the problem, but I'm not sure I like the proposed
solution.

Is there any situation where a process group leader exits and you
still want processes in that group to be allowed to access the tty?
My brain gets tied up in knots when I try to follow what POSIX says
about this sort of thing, especially since POSIX constantly refers to
sessions and MiNT doesn't have sessions.  But I *think* that once the
process group leader has exited, all remaining processes in that
process group should be denied access to the terminal (by getting EIO
in response to any attempted read or write).  But MiNT doesn't have
EIO currently, and I'm not sure how programs that aren't expecting it
will respond if it is suddenly added.

Am I making any sense?  Maybe we really need to add the concept of a
session to MiNT in order to get job control working in a sane manner...

--
entropy -- it's not just a good idea, it's the second law.
Personal mail:      entropy@gnu.ai.mit.edu
MiNT library mail:  entropy@terminator.rs.itd.umich.edu
"what do you have against octal?" -jrb