signal problems on BSD

[Maarten Litmaath]

In article <1990Mar8.084830.9252 at athena.mit.edu>,
	jik at athena.mit.edu (Jonathan I. Kamens) writes:
)...
)> )  Here at Project Athena, we have a hack in our /bin/login which makes
)> )it possible to do what you want, although I don't know how universal
)> )this is (it isn't in the vanilla 4.3-tahoe sources, which means it isn't
)> )a standard 4.3bsd thing).  After the child process (i.e. the login
)> )shell) of /bin/login exits, /bin/login does "killpg(child, SIGHUP)",
)> )where "child" is the process group of the child.
)> 
)> Why don't you let the kernel or init(8) do the killpg()?  Now you have an
)> extra process hanging around, doing nothing but wait()ing.
)
)  Because I believe that the kernel SIGHUP functionality only works when
)a dialup line or a hard-wired terminal line (i.e. something that init
)deals with, I believe) is the login tty in question.

Not necessarily.  Here's a little excerpt from the SunOS pty `deallocate'
routine:

        if (tp->t_state & TS_ISOPEN)
                gsignal(tp->t_pgrp, SIGHUP);
        tp->t_state &= ~TS_CARR_ON;     /* virtual carrier gone */

You're right insofar that init(8) can't offer the SIGHUP service for ptys.

)...
)> I assume you wrote a utility `hup' (the opposite of nohup(1)) too:
)...
)> 	a) to do this setpgrp() for you (!)
)> 	b) to catch the keyboard signals (!!)
)
)  What do you mean by "keyboard signals"??

If you setpgrp() to your parent's group, and this parent happens to be in
the foreground, *you* will receive keyboard signals too.

	% cat c.c
	main()
	{
		if (setpgrp(0, getpgrp(getppid())) < 0)
			perror("setpgrp");
		pause();
	}
	% cc c.c
	% a.out &
	[1] 6338
	% ^?
	[1]    a.out
	% kill -0 6338
	6338: No such process
	% a.out &
	[1] 6349
	% ^\
	[1]    Quit                 a.out (core dumped)
	% 

Remarks:
-	`^?' denotes `DEL' (interrupt);
-	csh seems to get confused about process 6338.
--
 1) Will 4.5BSD have wait5()?         |Maarten Litmaath @ VU Amsterdam:
 2) Sleep(3) should be sleep(2) again.|maart at cs.vu.nl, uunet!mcsun!botter!maart