On Fri, 30 Aug 2024 at 04:17, Robert Elz <k...@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
