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

[Steffen Nurpmeso]

Chet Ramey wrote in
 <eb824cbd-dabe-4868-a3ec-4c9fd478d9c9@case.edu>:
 |On 8/29/24 2:17 PM, Robert Elz wrote:
 |>      Date:        Thu, 29 Aug 2024 10:40:25 -0400
 |>      From:        Chet Ramey <chet.ramey@case.edu>
 |>      Message-ID:  <b1ae5f45-a9fe-407f-8a76-6e36e7248166@case.edu>
 |> 
 |>| It's not a big problem. You're in the background if your process \
 |>| group is
 |>| not equal to the terminal's process group.
 |> 
 |> That's more or less sufficient to determine if the process is in \
 |> a background
 |> job - but being a background process simply means that the shell \
 |> is not waiting
 |> for it to complete, before doing other things.
 |
 |Sure, but you have to play the percentages. In the non-job-control case,
 |you don't have any way to check and can't do really anything if you manage
 |to find out you're in the background.
 |
 |> If that's true then the system's definition of how tostop works is \
 |> broken.
 |> "stty tostop" means "stop the process (group) if an attempt is made to
 |> send output to the terminal".   The stop is done by sending SIGTTOU.
 |
 |Setting the window size will send SIGTTOU. If you want to stop if you're
 |not in the foreground, that's an easy, transparent way to do it.

Btw i simply raise SIGTSTP to myself, reasoning that if we want to
fiddle with termios then because we need to be in the foreground.
Thanks again for noting bg(1)!
(Ie we do not access the terminal at all until we are in the
foreground; it, however, does not distribute to other members of
the process group, which possibly needs more thought.  Maybe
kill(-XY) instead of raise.  And maybe TTOU instead of TSTP.)

 |>| 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.
 |
 |Yeah, but that's the problem here. If you're going to fetch the terminal
 |attributes and restore them later, you want to make sure you're in the
 |foreground when you do it. You don't know what the foreground process has
 |modified -- in this case, readline set up the terminal to do editing
 |input before Mail fetched the attributes. That way, even if you're in the
 |foreground when you finally exit and restore the terminal attributes,
 |they're the right ones.
 |
 |The safest way to do that is to either force the stop at startup, or before
 |you try to fetch the terminal attributes. Don't try to ignore SIGTTIN or
 |SIGTTOU. Or you could fetch the attributes every time you get a SIGCONT
 |and trust that the shell does the right thing.

SIGCONT and rechecking whether you are in the foreground; i bend
SIGCONT to TSTP if that is not the case (for the re-raise; again,
maybe to be changed to kill and TTOU; 'thing is, without condome
we effectively would cause TTIN at times, which i see no way of
"faking" for (also because it then happens from within other code
parts, the line editor, to be exact), so bending occurs anyway).

I have given you credit because this bg thing i would not have
thought of, coming to a different implementation thus.

--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)