Re: Does anyone understand terminal job control?

[Daniel Burrows <dburrows@algebraicthunk.net>]

On Sun, Feb 08, 2009 at 11:15:46PM +0100, Mirko Parthey <mirko.parthey@informatik.tu-chemnitz.de> was heard to say:
> On Sat, Feb 07, 2009 at 04:58:13PM -0800, Daniel Burrows wrote:
> > directly under my controller process.  It's not even that they're
> > starting as foreground processes: I can start them without access to
> > the controlling terminal, and they never see a SIGTTIN.
> 
> What do you mean by: "without access to the controlling terminal"?
> Is the controlling terminal actually connected to the stdin of your
> subprocess in the normal case (check in /proc to be sure)?

  I was being sloppy :)  -- I meant that the terminal has been "taken
away" via tcsetpgrp().

> The libc info also has example code for implementing a shell with job
> control, but I haven't looked at it closely yet.

  Yeah, that's basically what I was basing my ideas on.

  The fundamental issue seems to be that the subprocess has to actually
issue a read() system call in order to be stopped.  For normal shells
this isn't a problem: if the subprocess is blocked in select() that's
OK (it's not actually messing with the terminal stream), and as soon as
the user types something, it'll wake up, try to read(), and get
suspended.  I'm just (ab)using this in an unusual way to detect when a
background process is trying to read from a hidden terminal.
Unfortunately, there's nothing in this scenario that would kick it out
of the select() and into read(), so I can't detect the reader.

  Daniel