bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: signals ignored in a subshell


From: Chet Ramey
Subject: Re: signals ignored in a subshell
Date: Mon, 6 Apr 2020 10:10:47 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]