[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bash passes changed termios to backgrounded process(es) groups?
From: |
Martin D Kealey |
Subject: |
Re: bash passes changed termios to backgrounded process(es) groups? |
Date: |
Thu, 29 Aug 2024 14:33:07 +1000 |
On Thu, 29 Aug 2024 at 06:12, Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
> Chet Ramey wrote in
> <3ca901aa-5c5e-4be3-9a71-157d7101f892@case.edu>:
> |On 8/27/24 7:46 PM, Steffen Nurpmeso wrote:
> |> ..and it seems that if bash starts a normal process then ICRNL is
> |> set, but if it starts a (process)& or only process&, then not!
> |> (I was about to send this to bug-readline first.)
> |
> |Under no circumstances should a background process attempt to fetch or
> |modify terminal attributes. Why isn't your Mail process checking for
> that?
>
> How could it do so?
> (getpid()==tcgetpgrp() or what the function name is is the only
> idea i have, but note it is false for (EXE), too. *Big problem*!)
>
You'd want getpgid() or getpgrp(), rather than getpid(). (On Linux,
getpgrp() returns the same as getpid() to the process group leader, but
that's *not* true on *BSD & Darwin.)
Having said that, it's more likely that Mail is actively doing something it
shouldn't be doing, and stopping doing it will suffice to fix the issue.
My first guess would be blocking or ignoring SIGTTIN and/or SIGTTOU.
The default behaviour is for a background process to receive SIGTTIN or
SIGTTOU when it attempts to interact with its controlling terminal. Indeed,
not just the process itself, but every other process in the same process
group too.
And the default action in response to those signals is to stop, the same as
SIGSTOP. SIGTTIN is always sent if you try to read from the tty, but
SIGTTOU is only send after "stty tostop" or equivalent.
So the main thing to do is to *avoid* ignoring or blocking those signals,
and to remove "stty -tostop" from your ~/.profile (or to add "stty tostop"
and complain to your OS vendor about their stupid default).
My memory is a little hazy on what happens if you attempt tcgetattr() or
tcsetattr() without otherwise reading or writing; in that case I suspect it
doesn't send either signal right away; so perhaps then the fix is simply to
try writing a welcome banner (or even just a single NL char) before
attempting tcgetattr(). (Maybe a zero-sized read or write might suffice?)
-Martin
- 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, 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/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