Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Denys Vlasenko <dvlasenk@redhat.com>
Newsgroups: gnu.bash.bug
Subject: Re: "wait" loses signals
Date: Fri, 21 Feb 2020 17:48:40 +0100
Lines: 42
Approved: bug-bash@gnu.org
Message-ID: <mailman.1371.1582303732.2412.bug-bash@gnu.org>
References: <750d460d-b8a4-4157-1488-9f4d9f973715@redhat.com> <35034c85-fd5a-5034-a2d5-e3903888069d@case.edu> <cf7adbec-e705-1071-34e1-50f8188f0edc@redhat.com> <d60f1dbc-990d-7291-e075-b67c07f61a86@case.edu> <00620c20-19ea-e71e-dc1b-926847901f82@redhat.com> <dab35be8-4b56-5887-bfa4-37ea7383864a@case.edu> <aa9b78f2-887e-4bea-ab84-fdfd16885cb7@redhat.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Harald van Dijk <harald@gigawatt.nl>
To: chet.ramey@case.edu, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
In-Reply-To: <dab35be8-4b56-5887-bfa4-37ea7383864a@case.edu>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:15950



On 2/21/20 4:07 PM, Chet Ramey wrote:
> On 2/21/20 9:44 AM, Denys Vlasenko wrote:
> 
>>>> Yes, and here we are "after command", specifically after "{...} &" command.
>>>> Since we got a trapped signal, we must run its trap.
>>>
>>> Did you look at the scenario in my message?
>>
>> What scenario?
> 
> The scenario in the message you replied to.
> 
>> As I said, there are just two possibilities:
>> signal is received before the point when shell checks for received
>> signals after "{...} &" command;
>> or signal is received after that point, and thus signal is
>> considered to be received "inside wait builtin".
> 
> That's just not reasonable.

Yes it is.

> You're saying signals that are received before
> the wait builtin begins executing (say, while the command is being parsed,
> or the shell is doing some other bookkeeping task) should be considered
> to have arrived while the wait builtin is executing.

OF COURSE! How else do you think this can possibly be seen?

> I'm pretty sure that's
> not consistent with the letter or the spirit of the standard.

IOW, you think that between "command 1 finished executing"
and "command 2 starts executing" there can be sort of signal black hole
time period, where signals can be simply ignored.

Now *this* is just not reasonable, since this would make traps
unreliable.