Shell's process group ID = foreground job's process group ID?

Question

I decisively conclude that Shell's process group ID = foreground job process group ID from the 2 sources below. When a background job is selected to run in the foreground, is it the shell's process group ID that changes to the foreground job's process group ID or the reverse?

1.

To facilitate the implementation of the user interface to job control, the operating system maintains the notion of a current terminal process group ID. Members of this process group (processes whose process group ID is equal to the current terminal process group ID) receive keyboard-generated signals such as SIGINT. These processes are said to be in the foreground. Background processes are those whose process group ID differs from the terminal’s; such processes are immune to keyboard-generated signals. (Source)

2.

UNIX.SE

Addition:

$sleep 3000 &
$sleep 2000 &
$ps xao pid,ppid,pgid,sid,tty,comm | grep tty

PID     PPID    PGID    SID     TTY     COMMAND
1153    1135    1153    1153    tty1    bash
1173    1153    1173    1153    tty1    sleep
1189    1153    1189    1153    tty1    sleep
1219    1153    1219    1153    tty1    ps
1220    1153    1219    1153    tty1    grep

Answer 1

I decisively conclude that Shell's process group ID = foreground job process group ID from the 2 sources below.

You shouldn't, since neither of the sources you quote claim that the shell's PGID is equal to the foreground job PGID.

The shell's PGID does not change. In a normal scenario with an interactive shell running in a terminal, the shell is in its own process group and the shell's PGID is equal to the shell's PID.

Each process has a PGID. The terminal has an associated foreground process group ID. The foreground process group is, by definition, the process group with that PGID.

Note that if the terminal is provided by a terminal emulator, there is no relation between any of this and the PID of the terminal emulator process. This should be obvious if you think of hardware terminals, provided entirely by the kernel: there's no terminal emulator process in that situation.

The terminal's associated PGID can be set by the tcsetpgrp function, which is called by the shell when it starts an external program in the foreground, or moves a job into the foreground with fg.

Answer 2

The idea comes from csh from Bill Joy from around 1979 1980. The related kernel support was added by Bill Joy to enable this feature at all.

Because the original csh was written with vfork() support at that time already, it is hard to understand the code from csh as vfork() requires to revert effects in the parent from actions in the child that are a result of the shared memory between parent and child in vfork().

If you like to understand a working implementation, I recommend to read the Bourne Shell source code.

The shell when it starts checks whether it is a process group leader or not and if needed makes itself a process group leader.

Of course, the shell keeps this id during it's lifetime unless it was not a process group leader at startup and it likes to suspend itself. Note that this is not fully supported in bash...

To make started jobs managable, each job is run in a separate new and own process group id.