> Date:Mon, 24 Feb 2020 06:44:12 -0800
> From:"Daniel Colascione"
> Message-ID:
>
> | That executing traps except in case you lose one rare race is
> painfully
> | obvious.
>
> Maybe you misunderstand the issue, no traps are lost, if they were
> that would indeed
Date:Mon, 24 Feb 2020 06:44:12 -0800
From:"Daniel Colascione"
Message-ID:
| That executing traps except in case you lose one rare race is painfully
| obvious.
Maybe you misunderstand the issue, no traps are lost, if they were
that would indeed be a bug, the
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
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
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.
>
On 2/20/20 4:27 PM, Chet Ramey wrote:
On 2/20/20 3:02 AM, Denys Vlasenko wrote:
On 2/19/20 9:30 PM, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought
On 20/02/2020 15:55, Robert Elz wrote:
Date:Thu, 20 Feb 2020 09:16:05 +
From:Harald van Dijk
Message-ID:
| In that case, I think we can interpret the "when" in the description
| of the trap command literally except when 2.11 overrides it.
I think it
Date:Thu, 20 Feb 2020 09:16:05 +
From:Harald van Dijk
Message-ID:
| In that case, I think we can interpret the "when" in the description
| of the trap command literally except when 2.11 overrides it.
I think it should be interpreted just like its normal
On 2/20/20 3:02 AM, Denys Vlasenko wrote:
> On 2/19/20 9:30 PM, Chet Ramey wrote:
>> On 2/19/20 5:29 AM, Denys Vlasenko wrote:
>>> A bug report from Harald van Dijk:
>>>
>>> test2.sh:
>>> trap 'kill $!; exit' TERM
>>> { kill $$; exec sleep 9; } &
>>> wait $!
>>>
>>> The above script ought exit
On 20/02/2020 01:55, Robert Elz wrote:
Date:Wed, 19 Feb 2020 23:53:56 +
From:Harald van Dijk
Message-ID: <9b9d435b-3d2f-99bd-eb3d-4a676ce89...@gigawatt.nl>
| POSIX says in the description of the trap command "Otherwise, the
| argument action shall be
On 2/19/20 9:30 PM, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is
Date:Wed, 19 Feb 2020 23:53:56 +
From:Harald van Dijk
Message-ID: <9b9d435b-3d2f-99bd-eb3d-4a676ce89...@gigawatt.nl>
| POSIX says in the description of the trap command "Otherwise, the
| argument action shall be read and executed by the shell when one of
On 19/02/2020 20:30, Chet Ramey wrote:
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is
On 2/19/20 5:29 AM, Denys Vlasenko wrote:
> A bug report from Harald van Dijk:
>
> test2.sh:
> trap 'kill $!; exit' TERM
> { kill $$; exec sleep 9; } &
> wait $!
>
> The above script ought exit quickly, and not leave a stray
> "sleep" child:
> (1) if "kill $$" signal is delivered before "wait",
A bug report from Harald van Dijk:
test2.sh:
trap 'kill $!; exit' TERM
{ kill $$; exec sleep 9; } &
wait $!
The above script ought exit quickly, and not leave a stray
"sleep" child:
(1) if "kill $$" signal is delivered before "wait",
then TERM trap will kill the child, and exit.
(2) if "kill
24 matches
Mail list logo
