Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!vrdxhq!bms-at!stuart
From: stuart@bms-at.UUCP (Stuart D. Gathman)
Newsgroups: comp.os.minix
Subject: Re: Process group initialization (was: SIGNAL Handling Problems)
Message-ID: <394@bms-at.UUCP>
Date: Tue, 19-May-87 15:18:26 EDT
Article-I.D.: bms-at.394
Posted: Tue May 19 15:18:26 1987
Date-Received: Sat, 23-May-87 03:58:21 EDT
References: <3882@cae780.TEK.COM> <2508@ncoast.UUCP> <1019@ark.cs.vu.nl>
Organization: Business Management Systems, Inc., Fairfax, VA
Lines: 18
Summary: Not in Sys V it doesn't. . .

In article <1019@ark.cs.vu.nl>, rmgtkro@cs.vu.nl (Rob ten Kroode) writes:

> I don't agree. A process should inherit it's parent's process group (unless

	agreed.

> The action of setpgrp() is NOT to set the caller's process group to it's pid.
> Setpgrp() has two arguments: a pid, and a process group. Setpgrp() puts the 

	In my Sys V manual, setpgrp() has no parameters and sets the
	caller's pgid to it's pid.  INIT's pgid is itself.  When
	forking off a login shell, a setpgrp() is done before the
	exec.  Thus, INIT is immune from signals from user process
	groups.

	Perhaps 4.3 is different?
-- 
Stuart D. Gathman	<..!seismo!dgis!bms-at!stuart>