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

[Martin D Kealey]

On Fri, 30 Aug 2024 at 04:17, Robert Elz <kre@munnari.oz.au> wrote:

> SIGTTOU is also sent, unconditionally, by any attempt to change any of
> the terminal's attributes, and the process (group) (by default) stops.
> (I don't recall off hand whether simply fetching the attributes is
> enough to generate SIGTTOU.)   Just as there's no stty option to avoid
> SIGTTIN (reading from the terminal) there's no option to avoid this
> kind of SIGTTOU - or there shouldn't be.
>

I've encountered something related to this, where the shell takes charge of
the terminal, away from another process that is using it.

This happens when trying to debug a modified version of Bash, with "gdb
./bash" then "run".
Gdb then stops twice before Bash prints its prompt, even though Bash
doesn't (seem to) print or read anything.

I assume that when gdb stops, the bash process underneath it will stall
when it hits something that gdb needs to be told about; or if not then,
when the outer shell regains control and resets the tpgrp to itself, the
inner shell would get SIGTTOU or SIGTTIN.

I was left wondering "why just twice", rather than once, not at all, or
repeating indefinitely; being triggered by tcsetattr could account for that.

  | Sure. But if you are restarted (and get your SIGCONT) due to the
> equivalent
>   | of a `bg', you still have to check whether you're in the foreground.
>
> Well, kind of, the more common approach, by most applictions, is to not
> bother to test, never ignore SIGTTIN/SIGTTOU, and simply go ahead and do
> whatever is needed,
> if the process stops because of one of those, and then is resumed as a
> background job, it will simply stop again when whatever made it stop is
> repeated.
> When it is resumed in foreground, it can do whatever is needed, and then
> (perhaps) be moved back to background later.
>

That's definitely where I was trying to go with my initial response, but
you've explained it better.

-Martin