signal problems on BSD

[Jonathan I. Kamens]

In article <5913 at star.cs.vu.nl>, maart at cs.vu.nl (Maarten Litmaath) writes:
> It's always been the kernel.  Quoting from termio(4) on SunOS 4.0.3c:

  Well, first of all, it's tty(4) in BSD, which is what I was talking
about.  Just a a small nit :-)

> )doesn't happen in csh.  Therefore, the reason your process is not
> )getting the signal is because the signal is never sent.
> 
> ...because csh puts each job into its own process group and a the group of a
> background job never equals the tty process group (by definition!).

  Yes, I should have let that specifically.

> )  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.  We don't use
hard-wired tty's here at Project Athena, we use pty's almost exclusively
(Remember, the X Window System was INVENTED at Project Athena :-).

> I assume you wrote a utility `hup' (the opposite of nohup(1)) too:

  No, actually, although it's an interesting idea.  I'll have to think
about it some more :-)

> 	a) to do this setpgrp() for you (!)
> 	b) to catch the keyboard signals (!!)

  What do you mean by "keyboard signals"??

Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik at Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8495			      Home: 617-782-0710