dash.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Harald van Dijk <harald@gigawatt.nl>
To: Jilles Tjoelker <jilles@stack.nl>
Cc: Steffen Nurpmeso <steffen@sdaoden.eu>,
	DASH shell mailing list <dash@vger.kernel.org>,
	Denys Vlasenko <vda.linux@googlemail.com>
Subject: Re: dash, busybox sh 1.32.0, FreeBSD 12.2 sh: spring TTOU but should not i think
Date: Sun, 10 Jan 2021 23:56:00 +0000	[thread overview]
Message-ID: <e66acdb5-9a1b-c8ee-38d1-cb04af914cbd@gigawatt.nl> (raw)
In-Reply-To: <bf6e1634-e472-1e9f-056a-ae98be7ec9d1@gigawatt.nl>

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.

Harald van Dijk

  parent reply	other threads:[~2021-01-10 23:57 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-19 17:28 Steffen Nurpmeso
2020-12-19 22:21 ` Steffen Nurpmeso
2020-12-19 23:52   ` Harald van Dijk
2020-12-21 16:24     ` Jilles Tjoelker
2020-12-21 19:43       ` Steffen Nurpmeso
2020-12-23 20:18       ` Harald van Dijk
2020-12-24 15:29         ` Jilles Tjoelker
2021-01-10 23:56         ` Harald van Dijk [this message]
2021-01-06  4:46       ` Herbert Xu
2021-01-06  4:45     ` [PATCH] jobs: Block signals during tcsetpgrp Herbert Xu
2021-01-06 21:16       ` Harald van Dijk
2021-01-06 22:41         ` Jilles Tjoelker
2021-01-07  7:36         ` Denys Vlasenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e66acdb5-9a1b-c8ee-38d1-cb04af914cbd@gigawatt.nl \
    --to=harald@gigawatt.nl \
    --cc=dash@vger.kernel.org \
    --cc=jilles@stack.nl \
    --cc=steffen@sdaoden.eu \
    --cc=vda.linux@googlemail.com \
    --subject='Re: dash, busybox sh 1.32.0, FreeBSD 12.2 sh: spring TTOU but should not i think' \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).