SIGTTOU handling

[cerise]

Hi:

I'm having some trouble with bash -- it doesn't seem
to be a problem with bash, but rather in my understanding
of how job control works.  This seemed like a pretty good
place to start looking for the sort of help I need on this.

At present, I'm writing what I call a terminal repeater.
It allocates a unix socket and a pty.  It forks and the
parent process becomes a pretty typical server connection
which monitors for connections to the unix socket and
writes to the pty.  When a write occurs to the pty, the 
parent process repeats that write to each of the 
connections to the unix socket.  Using this method, the
exact screen contents can be duplicated to a number of
viewers.

I had some difficulties getting job control working at
first.  I found that having the child process do a 
setpgrp() before forking to the bash instance made the
error message about disabling job control go away.

The problem for which I'm seeking help deals with the
way bash handles the SIGTTOU signal.  I can duplicate
the problem by typing "less /etc/passwd &".

When I do this under a normal bash process, I get:
$ less /etc/passwd &
[1] 28054
$

[1]+  Stopped less /etc/passwd
$ 


When I launch this under my repeater, I get:
$ less /etc/passwd &
[1] 28473
$

[1]+  Stopped(SIGTTOU)less /etc/passwd
$


Under a normal bash process, I can then foreground
it and everything works the way it ought to.  However,
if I try to foreground it under the bash process running
on top of my repeater, I get:
$ fg
less /etc/passwd

[1]+  Stopped(SIGTTOU)less /etc/passwd
$

My assumption is that I'm not setting up something 
correctly before running my execl to bash because I'm
not seeing similar behavior in bash on either side.

Can someone provide a hint to this end?  My deepest
thanks for your time and any advice you might be
able to provide.

-Phil

Re: SIGTTOU handling

[cerise]

Hi Derek:

Thanks for the input.  

I know that stderr is duplicated, so that's not a problem.  I long
suspected terminal problems, but I know that openpty is setting
the term correctly from when I was mucking around with whether or
not I wanted the terminal running in canonical mode.

I changed out the call to setsid, but that didn't change anything.
I've also tried using tcsetpgrp() and calling fork() and exit() to 
make the shell an orphaned process -- neither of which seemed to
do any good.

I used to suspect that the pty wasn't set up correctly and I
eventually ended up duplicating the termios structure bit by
bit and setting the pty to the characteristics that a pty from
ssh gets, but that didn't do the trick either.  That suggests
to me that the problem isn't terminal related, but rather that
it's related to the setup of the child process.  Maybe this is
the fault of an environment variable?

-Phil