Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #16100

Re: signals ignored in a subshell

Show key headers only | View raw

On 4/6/20 5:12 AM, Robert Elz wrote:
>     Date:        Sun, 5 Apr 2020 16:21:53 -0400
>     From:        Chet Ramey <chet.ramey@case.edu>
>     Message-ID:  <45c766ba-4489-bd7b-40c7-32fed37461f9@case.edu>
> 
>   | That's not how read is defined to behave. wait has special wording defining
>   | what happens when it receives a signal.
> 
> No, it doesn't, that's a misreading of the standard.

I wonder if we're talking about the same thing. I'm talking about how the
standard says wait will return immediately and then execute the trap
handler. There's no such wording for read, so there is some freedom in when
the trap handler gets executed. Bash does it in the context of `read',
before any specific return.

> bash and zsh seem to be the only shells that treat read this way, and
> bash doesn't do it in POSIX mode, which means, I believe that you're
> aware that you're treating read specially, and that what POSIX says about
> it is irrelevant.

Bash has implemented `read' this way forever, and backwards compatibility
is an issue. POSIX mode is posix mode: that's where what posix says has
relevance, and why bash behaves differently.

The better question, I think, is whether a posix-mode bash should
(logically) return from the read builtin before running the trap handler,
or run the trap handler and then return. That has implications for what the
OP was trying to do: a recursive trap handler.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: signals ignored in a subshell Chet Ramey <chet.ramey@case.edu> - 2020-04-06 10:10 -0400

csiph-web