Path: csiph.com!goblin3!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Chet Ramey <chet.ramey@case.edu>
Newsgroups: gnu.bash.bug
Subject: Re: "wait" loses signals
Date: Fri, 21 Feb 2020 10:07:25 -0500
Lines: 28
Approved: bug-bash@gnu.org
Message-ID: <mailman.1365.1582297655.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>
Reply-To: chet.ramey@case.edu
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: chet.ramey@case.edu, Harald van Dijk <harald@gigawatt.nl>
To: Denys Vlasenko <dvlasenk@redhat.com>, bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Autocrypt: addr=chet.ramey@case.edu; prefer-encrypt=mutual; keydata= mQGiBEEOsGwRBACFa0A1oa71HSZLWxAx0svXzhOZNQZOzqHmSuGOG92jIpQpr8DpvgRh40Yp AwdcXb8QG1J5yGAKeevNE1zCFaA725vGSdHUyypHouV0xoWwukYO6qlyyX+2BZU+okBUqoWQ koWxiYaCSfzB2Ln7pmdys1fJhcgBKf3VjWCjd2XJTwCgoFJOwyBFJdugjfwjSoRSwDOIMf0D /iQKqlWhIO1LGpMrGX0il0/x4zj0NAcSwAk7LaPZbN4UPjn5pqGEHBlf1+xDDQCkAoZ/VqES GZragl4VqJfxBr29Ag0UDvNbUbXoxQsARdero1M8GiAIRc50hj7HXFoERwenbNDJL86GPLAQ OTGOCa4W2o29nFfFjQrsrrYHzVtyA/9oyKvTeEMJ7NA3VJdWcmn7gOu0FxEmSNhSoV1T4vP2 1Wf7f5niCCRKQLNyUy0wEApQi4tSysdz+AbgAc0b/bHYVzIf2uO2lIEZQNNt+3g2bmXgloWm W5fsm/di50Gm1l1Na63d3RZ00SeFQos6WEwLUHEB0yp6KXluXLLIZitEJLQgQ2hldCBSYW1l eSA8Y2hldC5yYW1leUBjYXNlLmVkdT6IYQQTEQIAIQIbAwYLCQgHAwIDFQIDAxYCAQIeAQIX gAUCRX3FIgIZAQAKCRC7WGnwZOp0q069AKCNDRn+zzN/AHbaynls/Lvq1kH/RQCgkLvF8bDs maUHSxSIPqzlGuKWDxa5AQ0EQQ6wbxAEAJCukwDigRDPhAuI+lf+6P64lWanIFOXIndqhvU1 3cDbQ/Wt5LwPzm2QTvd7F+fcHOgZ8KOFScbDpjJaRqwIybMTcIN0B2pBLX/C10W1aY+cUrXZ gXUGVISEMmpaP9v02auToo7XXVEHC+XLO9IU7/xaU98FL69l6/K4xeNSBRM/AAMHA/wNAmRB pcyK0+VggZ5esQaIP/LyolAm2qwcmrd3dZi+g24s7yjV0EUwvRP7xHRDQFgkAo6++QbuecU/ J90lxrVnQwucZmfz9zgWDkT/MpfB/CNRSKLFjhYq2yHmHWT6vEjw9Ry/hF6Pc0oh1a62USdf aKAiim0nVxxQmPmiRvtCmYhJBBgRAgAJBQJBDrBvAhsMAAoJELtYafBk6nSr43AAn2ZZFQg8 Gs/zUzvXMt7evaFqVTzcAJ0cHtKpP1i/4H4R9+OsYeQdxxWxTQ==
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
In-Reply-To: <00620c20-19ea-e71e-dc1b-926847901f82@redhat.com>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:15949

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. 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. I'm pretty sure that's
not consistent with the letter or the spirit of the standard.

-- 
``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/