of processes. With a shell that does not know about job control,
like <code>ash</code>, each of its children will be in the same session
and have the same process group as the shell. With a shell that knows
-about job control, like <code>bash</code>, the processes of one pipeline. like
+about job control, like <code>bash</code>, the processes of one pipeline, like
</p><blockquote>
<pre>% cat paper | ideal | pic | tbl | eqn | ditroff > out
</pre>
larger than 1 that is not a process group ID.
</p><p>A process can set the foreground process group in its session
using <code>tcsetpgrp(fd,pgrp)</code>, where <code>fd</code> refers to its
-controlling tty, and <code>pgrp</code> is a process group in the
+controlling tty, and <code>pgrp</code> is a process group in
its session, and this session still is associated to the controlling
tty of the calling process.
</p><p>How does one get <code>fd</code>? By definition, <code>/dev/tty</code>
becomes its controlling tty.
</p><p>The BSD approach is that one has to explicitly call
</p><blockquote>
-<pre>ioctl(fd, TIOCSCTTY, ...);
+<pre>ioctl(fd, TIOCSCTTY, 0/1);
</pre>
</blockquote>
(iii) maybe the tty should not already control some other session;
if it does it is an error if we aren't root, or we steal the tty
if we are all-powerful.
+[vda: correction: third parameter controls this: if 1, we steal tty from
+any such session, if 0, we don't steal]
</p><p>Opening some terminal will give us a controlling tty,
provided that (i) the current process is a session leader, and
(ii) it does not yet have a controlling tty, and