SysVR3.2 Setpgrp behaviour

[Chip Salzenberg]

According to kremer at cs.odu.edu (Lloyd Kremer):
>According to chip at ateng.com (Chip Salzenberg):
>>You should also do another fork() AFTER the setpgrp().  Otherwise, the child
>>process remains a process group leader.  And if a process group leader
>>without a controlling tty opens a tty that no other process has open at the
>>time [inhale], then that tty becomes the process's controlling tty.  So the
>>child must fork() again; then the grandchild process is a safe daemon.
>
>Do you need two forks?  Wouldn't the "second" fork alone be sufficient?

Unfortunately, the first fork() is required to ensure that setpgrp() will
work correctly.  You see, setpgrp() has two functions:

    1.  Make the process a process group leader.
    2.  Make the process have no controlling tty.

Here's the ugly part:  If function #1 isn't needed -- i.e. if the process is
already a process group leader -- then function #2 is _not_ performed.  In
other words, if a process is a process group leader, setpgrp() does nothing.
(Sigh.)

So summarize:  The fork() _before_ the setpgrp() guarantees that the child
isn't a process group leader, and thus ensures that setpgrp() will work,
losing the controlling tty.  The fork() _after_ the setpgrp() guarantees
that the grandchild won't ever get a controlling tty by accident.

Now you see why I said that setpgrp() is a grody hack.  :-(
-- 
You may redistribute this article only to those who may freely do likewise.
Chip Salzenberg at A T Engineering;  <chip at ateng.com> or <uunet!ateng!chip>
"'Why do we post to Usenet?'  Naturally, the answer is, 'To get a response.'"
                        -- Brad "Flame Me" Templeton