Date: Thu, 29 Aug 2024 10:40:25 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <b1ae5f45-a9fe-407f-8a76-6e36e7248...@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.
That is, consider a process proc and
set -m; proc &
set +m; proc &
The first proc will be in a different process group, the second proc will not.
They're both running in the background.
| before fetching the terminal attributes -- so it gets a SIGTTOU if it's
| in the background, even though that can be defeated by `stty -tostop'.
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.
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.
| 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.
kre
