On 23/12/2020 20:18, Harald van Dijk wrote:
On 21/12/2020 16:24, Jilles Tjoelker wrote:
Tradition is for job control shells to be a process group leader, but I
don't really know why. Changing this will not fix the issue entirely
anyway since the shell must perform tcsetpgrp() from the background when
a foreground job has terminated.
[...]
This should, in my opinion, *only* happen for interactive shells, not
for job-control-enabled non-interactive shells. [...]
Consider also an extra difficulty arising from this process group switching:
: | dash -m
When a job-control-enabled shell terminates, or when job control is
disabled via set +m, it attempts to re-join its initial process group
and set that as the foreground process group. This can fail if the
process group has ceased to exist after the shell left it, as it does
here, resulting in:
$ : | dash -m
dash: 0: Cannot set tty process group (No such process)
In theory, because of PID reuse, this may even result in some random
unrelated process group temporarily becoming the foreground process group.
I am leaning towards saying that once the shell has committed to
becoming a process group leader, it should remain one. By basing this on
the shell being interactive rather than on job control being enabled,
this is easier to handle, as as far as POSIX is concerned "interactive"
is a property that cannot be changed once the shell has started: set -i
and set +i are extensions not required by POSIX, and if they are
nonetheless supported it is easy to defend them not being fully
equivalent to specifying or leaving out -i on the shell invocation.
Cheers,
Harald van Dijk
