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

Groups > gnu.bash.bug > #15950

Re: "wait" loses signals

Show all headers | View raw

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.

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

Thread

Re: "wait" loses signals Denys Vlasenko <dvlasenk@redhat.com> - 2020-02-21 17:48 +0100

csiph-web