Re: Our /bin/sh and process group IDs

From: Jilles Tjoelker <jilles_at_stack.nl>
Date: Sat, 26 Mar 2022 19:39:50 UTC
On Sat, Mar 26, 2022 at 03:52:40PM +0100, Ganael Laplanche wrote:
> Le 25/03/2022 à 20:13, Bryan Drewery a écrit :

> Hello Bryan,

> > set -m needs to be set from the parent process, not child.

> Thanks for those clarifications.

> Is that something required by POSIX (I could not find any documentation
> about that) ? Or is it a limitation (or bug) of our implementation ? Other
> shells -mostly- do not behave that way (see my original post).

This appears to be a gray area, and the exact behaviour varies across
shells. For example, with  stty tostop  in effect,

sh -c '(set -m; echo "echo from background" & wait "$!"); echo "wait returns $?"'

has a variety of behaviours:

* with FreeBSD sh, dash and also ksh93, it prints both lines
* with mksh, it only prints the "wait returns 0" line
* with bash, it hangs (as expected with a new process group)

I think it is definitely undesirable for  set -m  to have an effect
across multiple levels of subshells by default, since it makes the
innermost processes immediately escape from the outer process group
supervision again.

As it is now, FreeBSD sh has implemented this by ignoring  set -m  from
a process other than the first process (so for example

sh -c '(set -m; echo "echo from background" & wait "$!"; echo "wait returns $?")'

still hangs with tostop in effect, since this particular subshell is
implemented without creating a new process), but perhaps this could be
extended a bit more.

> > In this  example test_func is a child *and* the sleep is a child which
> > is also very racy. Here's a pattern I use that works:
> > [...]

> Unfortunately, in my case, spawn would have to be called from a sub-process
> already forked (from a background function, executed as a child process) ;
> so that wouldn't work either. Anyway, thanks for the hint :)

A second workaround is to start a new instance of sh.

-- 
Jilles Tjoelker