[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dash
Subject:    Re: dash 0.5.11.2, busybox sh 1.32.0, FreeBSD 12.2 sh: spring TTOU but should not i think
From:       Harald van Dijk <harald () gigawatt ! nl>
Date:       2021-01-10 23:56:00
Message-ID: e66acdb5-9a1b-c8ee-38d1-cb04af914cbd () gigawatt ! nl
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]