Path: utzoo!attcan!telly!lethe!torsqnt!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mcsun!ukc!acorn!john
From: john@acorn.co.uk (John Bowler)
Newsgroups: comp.unix.questions
Subject: Re: Putting a curses program in the background then in the foreground
Message-ID: <843@acorn.co.uk>
Date: 22 Sep 89 17:48:32 GMT
References: <4013@augusta.UUCP> <BRISTER.89Sep21161941@aries.td2cad.intel.com>
Reply-To: john@acorn.UUCP (John Bowler)
Organization: Acorn Computers Ltd, Cambridge, UK
Lines: 30

In article <BRISTER.89Sep21161941@aries.td2cad.intel.com> brister@td2cad.intel.com (James Brister) writes:
>My guess about this sort of required behaviour is this:
>
>	i) the program catches the SIGTSTP signal. In the handler it reset the
>	   terminal characteristics and then sends itself a SIGSTOP.
>
>        ii) the program catches the SIGCONT signal. In the handler it does a
>	   refresh of the necessary stuff and then continues.
>

There's no need to catch SIGCONT, the relevant code fragment would be something
of the form:-

void catchTSTP(int sig) {
	resetty();
	kill(0,SIGSTOP);	/* In ANSI C raise(SIGSTOP); */
	savetty();
}

resetty() is a curses library function which resets the terminal, savetty()
saves the current settings.  The routine relies on the ``kill'' function
being synchronous.  (Otherwise some form of call to ``sigpause()'' would
be necessary - tricky because of the obvious race).  Effectively the ``kill''
call justs waits for SIGCONT.  All of this is wrapped up in the curses
tstp() routine, which is normally installed as the handler for SIGTSTP, but
can be called directly.  The only problem with all of this is dealing with
the Bourne shell (pre SVR4) - this has no job control, so raising SIGSTOP
tends to be unhealthy.

John Bowler (jbowler@acorn.co.uk)