Child Needs to Handle SIGTSTP Before Parent

[John Hoag]

A most perplexing problem, possibly without a solution... I don't know.
This is on a Sequent running a variant of 4.2BSD.  

Objective:  a simple front-end program (which I'll call FE, from here on)
to nn which will setup the user for terminal emulation (in the file
appropriate to the shell), redefine the TERM and TERMCAP in the FE, then
run nn.  All of the code for this has been written and works fine.

Problem:  Our version of nn (Release 6.4.9 #4), as compiled on our machine,
does not restore the terminal to its original state on receipt of a SIGTSTP
signal!  If you run nn directly from the csh, this doesn't represent a
problem because (apparently) the csh handles restoring the terminal
settings on SIGTSTP and resetting them back to nn's settings on SIGCONT.
However, if you run nn with a fork/exec from an intermediary process like
my FE program, the shell (apparently) sees only the intermediary process's
terminal settings, not nn's.  So what happens is:  when you run FE from
csh, then nn from within FE, then ^Z, you get to a csh without any echo.

OK, fine, sez I.  I'll just write the signal handlers into FE, around the
child nn process, so terminal settings get saved, restored and reset at the
proper times on receipt of SIGTSTP and SIGCONT.  Great.  Done.  Worked like
a charm.

Now here's the killer.  Predictably, many csh users will not be running FE
from a csh prompt, but from our conferencing software (which I'll call CS).
Our CS isn't a terminal emulated program, and doesn't do anything to the
terminal settings on its own.  Neither, unfortunately, does it save/restore
terminal settings on receipt of signals when running child processes.

So, we have a user doing this:

	csh -> CS -> FE -> nn -> ^Z

What happens is:  CS catches the signal before FE does! -- thus
circumventing all my fine signal handling and terminal restoration.  One
again ends up at a csh prompt without echo.  GAK!  Then one types "fg"
(without seeing it echoed), and one THEN goes through my SIGTSTP handler
which restores the terminal and calls kill(0, SIGTSTP) -- thus returning
one immediately back to the csh prompt, but this time with echo.  Then one
types "fg" and one (finally!) goes through my SIGCONT handler which
restores nn's terminal settings and returns you to nn -- and everything is
hunky-dorey.  Of course, that's hardly acceptable behavior.

I tried diddling with setting FE and CS to the same process group before
forking/execing nn, which did, indeed, drop me through my SIGTSTP handler
on the way to the csh prompt.  But then I got a bunch of "use logout to
logoff" messages and was disconnected.  This happened repeatedly without
fail.  Not sure why. 

I can't say I'm experienced with handling process groups specifically in my
code, but I'm hoping maybe an answer may still lie in that direction.
Right now, however, I'm simply disabling ^Z and advising csh users to run
nn directly from a csh prompt.

I'm sorry the preamble to my question is so long, but I don't know of a
shorter way to explain it.

My question is this:  Is there a way I can get my program (FE), when it's
the child of a child of the csh, to grab that SIGTSTP signal away from its
parent process so it can handle the terminal settings without intervention
by its parent?  

Secondly, is there a way I can have my program know, not just the ppid, but
the *name* of its parent process, so I can tell whether it's being run from
the csh or from an intermediary process?

It's a weird situation, I know.  Ultimately, the fault lies with our
installation of nn, which should be handling its own terminal restorations.
Unfortunately, for reasons I needn't go into here, we can't recompile our
version of nn any time soon, and certain source code files are missing --
which makes tracking the problem through nn impossible.  (BTW, does a
properly installed nn handle terminal settings correctly in the above
scenario, or is it a known bug in nn proper?)

Any thoughts on a possible solution/approach (aside from diddling with nn's
code) would be most sincerely appreciated.
-- 
------------------------------------------------------------------------
             John Hoag - loca at well.sf.ca.us - apple!well!loca
------------------------------------------------------------------------