[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash passes changed termios to backgrounded process(es) groups?
From: |
Steffen Nurpmeso |
Subject: |
Re: bash passes changed termios to backgrounded process(es) groups? |
Date: |
Fri, 30 Aug 2024 00:39:40 +0200 |
User-agent: |
s-nail v14.9.25-599-g5c75a327b2 |
Robert Elz wrote in
<25564.1724955459@jacaranda.noi.kre.to>:
| 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.
|
|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
No. On Linux it seems not even to cause TTOU if you set
attributes which are effectively identical to what is already
active, unless i got that wrong. (Which could very well have been
so.)
|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
--End of <25564.1724955459@jacaranda.noi.kre.to>
--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)
- Re: bash passes changed termios to backgrounded process(es) groups?, (continued)
- Re: bash passes changed termios to backgrounded process(es) groups?, Chet Ramey, 2024/08/28
- Re: bash passes changed termios to backgrounded process(es) groups?, Robert Elz, 2024/08/29
- Re: bash passes changed termios to backgrounded process(es) groups?, Martin D Kealey, 2024/08/29
- Re: bash passes changed termios to backgrounded process(es) groups?, Steffen Nurpmeso, 2024/08/29
- Re: bash passes changed termios to backgrounded process(es) groups?, Chet Ramey, 2024/08/30
- Re: bash passes changed termios to backgrounded process(es) groups?,
Steffen Nurpmeso <=
- Re: bash passes changed termios to backgrounded process(es) groups?, Robert Elz, 2024/08/29
- Re: bash passes changed termios to backgrounded process(es) groups?, Steffen Nurpmeso, 2024/08/29
- Re: bash passes changed termios to backgrounded process(es) groups?, Chet Ramey, 2024/08/30
- Re: bash passes changed termios to backgrounded process(es) groups?, Steffen Nurpmeso, 2024/08/30