Re: Monitor mode handling (bug ?)

[Jilles Tjoelker <jilles@xxxxxxxx>]

On Mon, Jan 09, 2023 at 04:18:02PM +0100, Ganael Laplanche wrote:
> Digging into a problem with a project of mine [1], I found dash (0.5.12) 
> behaves differently from other POSIX-compliant shells when dealing with 
> monitor mode when running in the background.

> In the following example, dash immediately sends a SIGTTIN signal that stops 
> the process group:

> $ cat test.sh
> set -m
> $ dash test.sh &
> [1]  + suspended (tty input)  dash test.sh

> while other shells do not:

> $ bash test.sh &
> [1]  + done       bash test.sh
> $ sh test.sh & # (/bin/sh from FreeBSD 13.1-RELEASE)
> [1]  + done       sh test.sh
> $ ksh93 test.sh &
> [1]  + done       ksh93 test.sh

> Is that an intended behaviour ?

The loop with SIGTTIN is the right thing for an interactive job control
shell. It ensures that two job control shells do not interfere. The idea
is that the user can later 'fg' from the outer job control shell.

The loop also helps with suspending a job control shell, for example via
the funcs/suspend function from the ash source (containing 'local -',
'set +m' and 'kill -TSTP 0'): when trying to resume the inner shell via
'bg' in the outer shell, it is this loop that makes the inner shell stop
itself.

However, for a non-interactive shell, monitor mode is most useful for
its effect of placing jobs in their own process groups. This does not
necessarily imply any tty manipulation.

To make this possible, feature was added to FreeBSD sh in
https://cgit.freebsd.org/src/commit/?id=cd60e2c67d52e1f957841af19128c7227880743a

This commit allows using job control without a tty in non-interactive
mode. Where an interactive shell disables job control with the message
  can't access tty; job control turned off
or stops itself because it is not in the foreground, a non-interactive
shell instead leaves a limited form of job control enabled that only
sets process group IDs on new processes and does not alter the
terminal's foreground process group ID.

> Also, the following test leads to dash looping indefinitely and eating 100% 
> CPU:

> $ cat test2.sh
> trap '' 21
> set -m
> $ dash test2.sh &

> It remains stuck within the following loop:

> https://git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/jobs.c?
> h=v0.5.12#n208

> Weird... Is that a dash bug or am I missing something?

Manipulating the disposition of TTIN/TTOU/TSTP with job control enabled
might be a question of "if it hurts, don't do that".

-- 
Jilles Tjoelker