Subject: Re: setpgid manpage omission? (+other q)
To: None <firstname.lastname@example.org>
From: Christos Zoulas <email@example.com>
Date: 12/17/2003 19:08:10
In article <20031217171554.GA11607@frohike.sshn.net>,
Peter Bex <Peter.Bex@student.kun.nl> wrote:
>I have some questions about setpgrp(2)/setpgid(2).
>- The manpage says:
>"setpgid() sets the process group of the specified process pid to the
>specified pgrp. If pid is zero, then the call applies to the current
>Doesn't pgrp == 0 have a special meaning as well? According to the (Red Hat)
>Linux manpage (no flames please, I'm just doing research):
>"If pgid is zero, the process ID of the process specified by pid is used."
>If this is correct, the NetBSD manpage should be updated.
This is correct.
>- What use does the statement setpgid(0,0) have? I don't see what that
>would do. My initial guess is that it simply sets the process group of the
>current process to the same it already is set to. What would be the benefits
>of doing such an operation? I'm trying to port plugger 5.0 to pkgsrc-wip, and
>it does this.
This is not true for all processes [i.e. interractive processes created by
shells in a pipeline all belong to the same process group].
>- Why the fsck does Linux do this:
>"In the Linux DLL 4.4.1 library, setpgrp simply calls setpgid(0,0)."
>if it's copied straight off the old BSD behaviour for backwards compatibility?
setpgrp() used to take 0 arguments on old svr systems, and 2
arguments on old BSD systems. setpgid() and the session stuff, were
created by POSIX to avoid security implications that the bsd
setpgrp() call had. Since the name setpgrp() was taken, and it had
different meanings depending on the OS, a new call was created
(setpgid()) so that the new semantics could be implemented,
co-existing with the old setpgrp() call. On BSD44 systems setpgrp()
== setpgid() (and we don't follow SUS setpgrp(void))