[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 01:28:48 +0200 |
User-agent: |
s-nail v14.9.25-599-g5c75a327b2 |
Martin D Kealey wrote in
<CAN_U6MVuezcmR2kn9duM-ahzYDA1J3zfEXwJHbc=dOKwJ2teyw@mail.gmail.com>:
|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.
...
|| 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,
..
|That's definitely where I was trying to go with my initial response, but
|you've explained it better.
Btw i disagree with this as i have seen conditions where the
terminal settings are not properly restored. That is one of the
reasons why we (who could run child processes doing "stuff) deal
with that. I think the proper way of doing that is handling TTOU,
restoring the "normal" terminal attributes within the signal
handler, then rereaise the signal after temporarily making it DFL,
causing it to stop. If all processes of the group which do modify
terminal settings do it that way, and all start with "normal"
attributes, then, even though lots of useless system calls happen,
everything is fine.
This belongs to the things which are stunning on Unix. Even
though pipes where there already in the early seventies, etc,
.. etc etc etc. The same for sigaction and signal by the way, why
it is impossible to set many in one system call. (On the other
hand, in SysV land, without signal restarting and jumping around,
you may very well get by with setting only once and then modifying
only masks, well.)
--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)
- bash passes changed termios to backgrounded process(es) groups?, Steffen Nurpmeso, 2024/08/27
- Re: bash passes changed termios to backgrounded process(es) groups?, Steffen Nurpmeso, 2024/08/27
- 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 <=
- 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/29
- 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