From: Harald van Dijk <firstname.lastname@example.org> To: Jilles Tjoelker <email@example.com> Cc: Steffen Nurpmeso <firstname.lastname@example.org>, DASH shell mailing list <email@example.com>, Denys Vlasenko <firstname.lastname@example.org> Subject: Re: dash 0.5.11.2, 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: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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
next prev 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: dash 0.5.11.2, busybox sh 1.32.0, FreeBSD 12.2 sh: spring TTOU but should not i think' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * 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).