Re: bash passes changed termios to backgrounded process(es) groups?

[Steffen Nurpmeso]

Martin D Kealey wrote in
 <CAN_U6MVdBX+8v69jGjkUowm5W-D5t5kNnSEHjBDBThf-nxeF_Q@mail.gmail.com>:
 |On Thu, 29 Aug 2024 at 06:12, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
 |> Chet Ramey wrote in
 |>  <3ca901aa-5c5e-4be3-9a71-157d7101f892@case.edu>:
 |>|On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
 |>|> ..and it seems that if bash starts a normal process then ICRNL is
 |>|> set, but if it starts a (process)& or only process&, then not!
 |>|> (I was about to send this to bug-readline first.)
 |>|
 |>|Under no circumstances should a background process attempt to fetch or
 |>|modify terminal attributes. Why isn't your Mail process checking for
 |> that?
 |>
 |> How could it do so?
 |> (getpid()==tcgetpgrp() or what the function name is is the only
 |> idea i have, but note it is false for (EXE), too.  *Big problem*!)
 |>
 |
 |You'd want getpgid() or getpgrp(), rather than getpid(). (On Linux,
 |getpgrp() returns the same as getpid() to the process group leader, but
 |that's *not* true on *BSD & Darwin.)

Thanks.  No way of "want"ing though :(

 |Having said that, it's more likely that Mail is actively doing something it
 |shouldn't be doing, and stopping doing it will suffice to fix the issue.
 |
 |My first guess would be blocking or ignoring SIGTTIN and/or SIGTTOU.

No no, *we* handle that.
We (off-topic for bug-bash@ i am afraid..) unfortunately do so
even if backgrounded, a condition we yet do not check.  I .. have
to wrap my head around how to avoid (re)setting terminal
attributes in that case; like i already have said this is a stack
of changes, but changing to "normal" state should not do anything
if there was no change to be undone at first (as opposed to "stack
exists" aka there is something .. i have done this i think half
a decade ago, and have to look).
We also must not believe the fetched "normal" state in
backgrounded situation, aka do not fetch it until we rise up from
the background the first time, at all.  I have to look how to do
this.

 |The default behaviour is for a background process to receive SIGTTIN or
 |SIGTTOU when it attempts to interact with its controlling terminal. Indeed,
 |not just the process itself, but every other process in the same process
 |group too.

Hm.

 |And the default action in response to those signals is to stop, the same as
 |SIGSTOP. SIGTTIN is always sent if you try to read from the tty, but
 |SIGTTOU is only send after "stty tostop" or equivalent.

Hm.

 |So the main thing to do is to *avoid* ignoring or blocking those signals,
 |and to remove "stty -tostop" from your ~/.profile (or to add "stty tostop"
 |and complain to your OS vendor about their stupid default).

Doing none of those.

 |My memory is a little hazy on what happens if you attempt tcgetattr() or
 |tcsetattr() without otherwise reading or writing; in that case I suspect it
 |doesn't send either signal right away; so perhaps then the fix is simply to
 |try writing a welcome banner (or even just a single NL char) before
 |attempting tcgetattr(). (Maybe a zero-sized read or write might suffice?)

I can assure you tcsettattr will rise TTOU *if* there is a mode
change.  (At least, and at least here and two nights ago or so.)

Thank you.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)