On 24/02/2020 08:59, Robert Elz wrote:
har...@gigawatt.nl said:
| In the same way, I think that except when overridden by 2.11, the "when"
| in "Otherwise, the argument action shall be read and executed by the
| shell when one of the corresponding conditions arises." should be
|
On 2/24/20 5:18 PM, Chet Ramey wrote:
The first case is trickier: there's always going to be a window between
the time the shell checks for pending traps and the time the wait builtin
starts to run. You can't really close it unless you're willing to run the
trap out of the signal handler, which
On 2/24/20 7:58 AM, Daniel Colascione wrote:
> No, it's not that much trouble to fix the bug. The techniques for fixing
> this kind of signal race are well-known. In particular, instead of
> waitpid, you use a self-pipe and signal the pipe in the signal handler,
> and you have a signal handler
On 2/24/20 3:59 AM, Robert Elz wrote:
> The relevance of this is that if a signal arrives while the wait command
> is executing (or as Chet suggested, while doing whatever housekeeping is
> needed to prepare to run it, like looking to see what command comes next)
> but before the relevant wait*()
> Date:Mon, 24 Feb 2020 04:58:31 -0800
> From:"Daniel Colascione"
> Message-ID: <07d1441d41280e6f9535048d6485.squir...@dancol.org>
>
> | That is a poor excuse for not fixing bugs.
>
> Only if they are bugs.
That executing traps except in case you lose one rare
Date:Mon, 24 Feb 2020 04:58:31 -0800
From:"Daniel Colascione"
Message-ID: <07d1441d41280e6f9535048d6485.squir...@dancol.org>
| That is a poor excuse for not fixing bugs.
Only if they are bugs.
| Maybe you can torture the standards into confessing that this
> There are lots of programming languages around, they each have their
> particular
> niche - the reason their inventors created them in the first place. Use
> an
> appropriate one, rather than attempting to shoehorn some feature that is
> needed
> into a language that was never intended for it
Date:Mon, 24 Feb 2020 11:50:55 +0100
From:Denys Vlasenko
Message-ID: <47762f41-e393-30cd-50ed-43c6bdd29...@redhat.com>
| This is racy. Even if you try to code is as tightly as possible:
Absolutely, I agree. The question is more whether it really matters.
|
On 2/24/20 9:59 AM, Robert Elz wrote:
And that is, when the wait/waitpid/wait3/wait4/waitid/wait6 (whatever the
shell uses) system call returns EINTR, the wait utility exited with a
status indicating it was interrupted by that signal (status > 128 means
128+SIGno) and runs the trap.
This is
Date:Fri, 21 Feb 2020 10:07:25 -0500
From:Chet Ramey
Message-ID:
| 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
10 matches
Mail list logo
