Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.aix
Subject: Re: losing /dev/tty ANSWERED
Message-ID: <2581@auspex.auspex.com>
Date: 28 Oct 89 18:52:16 GMT
References: <1163@msa3b.UUCP>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 36

>According to the Tech Ref Vol 1:
>   The setpgrp system call ... This is equivalent to setpgid(0,0).
>
>Well I say it is NOT.

And you are correct in saying so.

>After a "setpgrp()", /dev/tty is gone.  After "setpgid(0,0)" or
>"setpgid(getpid(),getpid())" /dev/tty is still there.
>
>I read in another newsgroup that SYSV (which has setpgrp) loses /dev/tty
>too.

AIX claims, as I understand it, to be S5-based, so it's not surprising
that they'd both act the same here.

>I suppose that the behavior is correct, but I sure wish they would
>document this difference.  I may try to get a doc APAR with IBM, if I have
>a little time to kill.

The problem is that AT&T never bothered to document that side effect of
"setpgrp", and I guess IBM didn't fix AT&T's bug there.  Fortunately,
with the advent of POSIX, this may all clean up somewhat; there are
separate "setsid()" and "setpgid()" calls (I presume AIX picked up
"setpgid()" from POSIX, or perhaps from the HP job control
implementation that, at least in part, inspired the POSIX proposal). 

"setsid()" basically replaces the S5 "setpgrp()", and takes away your
controlling tty; the POSIX spec explicitly says so, so I would assume
any documentation would say so as well.  "setpgid()" basically replaces
the 4.xBSD "setpgrp()", and doesn't take away your controlling tty.

S5R4 will be POSIX-compliant, "4.4BSD" will be (if, as, and when it
comes out), and AIX will, I presume, be so if it isn't so already.  Wow,
what a concept, the same process-group-manipulation code working on most
systems (modulo bugs), and no #ifdefs....