Re: Does anyone understand terminal job control?

[Daniel Burrows <dburrows@debian.org>]

On Mon, Feb 09, 2009 at 10:37:07AM -0500, "Douglas A. Tutty" <dtutty@vianet.ca> was heard to say:
> On Sun, Feb 08, 2009 at 08:27:09PM -0800, Daniel Burrows wrote:
> > On Sun, Feb 08, 2009 at 07:58:51AM -0500, "Douglas A. Tutty" <dtutty@vianet.ca> was heard to say:
>  
> > > Perhaps your controller program will have
> > > to be a filter between the process and the terminal: pipe its std-in an
> > > std-out to the controller process and the controller process issue the
> > > appropriate shell start/stop commands as necessary while leaving the
> > > process in the background the whole time.
> > 
> >   I thought about this option, but the problem is detecting when the
> > subprocess is trying to read (but I don't have anything to give it).
> > One interesting idea I got from the libc manual (but have yet to follow
> > up on) is to inject a VDSUSP character into the stream -- apparently
> > this will suspend the process, but only when the character is actually
> > read.  I vaguely recall having some reason to think it might not work,
> > but it's worth at least trying.  (as it happens, since I control the
> > terminal, I don't need a man in the middle to do this (I think) -- I
> > can just ask the terminal to send the character)
> > 
> 
> Wouldn't the process that is wanting to read from stdin from a user
> typically issue some sort of prompt for the user.  If your controlling
> program wasn't there, how would the user know that input was requried?
> Can't you listen for that prompt?

  Well, the problem is that I don't know what the prompt is.  e.g., if
I see

> Unable to build the frimblefroz database.  Some program functions
> might be inoperable until you run /usr/bin/update-frimblefroz.
>    Press [RETURN] to continue

  I guess the "press return to continue" could be hardcoded in since
many programs use it, but then what about "press [enter] to continue"?
It would be very hacky.  And then you get stuff like the debconf
whiptail dialogs that I was working with originally; there's no way I
can reliably detect that stuff (unless, again, I use some heuristic
like "if the terminal switches to its second screen there may be a
prompt"), plus who knows what third-party .debs do...

  I really want to avoid anything that involves collecting 50 different
heuristics to create a huge maintenance headache that won't quite work
anyway. :-)

  I mentioned the problem to some guys at work, and one of them had an
interesting idea, which is to watch the processes in the subprocess's
process group, and guess that they're waiting on input if none of them
are consuming any user time, or at least if they're consuming negligible
amounts of it (since they might block in select() with a timeout).  I
could also just imitate synaptic and guess that the program is waiting
if it's gone more than a couple minutes without generating output.

  Daniel