loca@well.sf.ca.us (John Hoag) (06/10/91)
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@well.sf.ca.us - apple!well!loca ------------------------------------------------------------------------