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


Groups > gnu.bash.bug > #15949

Re: "wait" loses signals

From Chet Ramey <chet.ramey@case.edu>
Newsgroups gnu.bash.bug
Subject Re: "wait" loses signals
Date 2020-02-21 10:07 -0500
Message-ID <mailman.1365.1582297655.2412.bug-bash@gnu.org> (permalink)
References (1 earlier) <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>

Show all headers | View raw


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/

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


Thread

Re: "wait" loses signals Chet Ramey <chet.ramey@case.edu> - 2020-02-21 10:07 -0500

csiph-web