Re: signals ignored in a subshell
Date:Sat, 4 Apr 2020 08:32:57 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| While waiting for read builtin to complete, bash executes signal handlers
| in a subshell where signals are ignored. See below.
|
| $ foo() { trap foo INT; read; }
What that says, is that when you get a SIGINT, call function foo().
When the read is interrupted by the ^C, SIGINT happens, the trap handler
runs, and foo is called again. That sets the trap handler all over again
(no real point, it was still set from before - trap handlers are not local
to function, except possibly the RETURN trap, that one I know nothing about)
and then does read. When you interrupt that one, SIGINT is generated,
the trap handler runs, and foo is called, which sets the trap handler
(yet again) and calls read ...
What were you expecting to happen?
The difference between the various shells depends upon exactly when in the
sequence of things the trap handler actually executes, in some shells it
might not be until after the initial foo function call finishes, in others,
it can happen immediately after the read terminates because of the SIGINT,
while foo is still running.
| Is this a bug or an undocumented feature?
It is bizarre broken application code.
kre
Re: signals ignored in a subshell
Thanks for the reply.
4 Nisan 2020 Cumartesi tarihinde Robert Elz yazdı:
> Date:Sat, 4 Apr 2020 08:32:57 +0300
> From:=?UTF-8?B?T8SfdXo=?=
> Message-ID: mail.gmail.com>
>
> | While waiting for read builtin to complete, bash executes signal
> handlers
> | in a subshell where signals are ignored. See below.
> |
> | $ foo() { trap foo INT; read; }
>
> What that says, is that when you get a SIGINT, call function foo().
>
> When the read is interrupted by the ^C, SIGINT happens, the trap handler
> runs, and foo is called again. That sets the trap handler all over again
> (no real point, it was still set from before - trap handlers are not local
> to function, except possibly the RETURN trap, that one I know nothing
> about)
> and then does read. When you interrupt that one, SIGINT is generated,
> the trap handler runs, and foo is called, which sets the trap handler
> (yet again) and calls read ...
>
>
Yes, I know.
> What were you expecting to happen?
>
>
I was expecting it to work (i.e interrupt read again and call foo) or show
an error on second SIGINT saying that's not allowed.
> The difference between the various shells depends upon exactly when in the
> sequence of things the trap handler actually executes, in some shells it
> might not be until after the initial foo function call finishes, in others,
> it can happen immediately after the read terminates because of the SIGINT,
> while foo is still running.
>
>| Is this a bug or an undocumented feature?
>
> It is bizarre broken application code.
>
> kre
>
>
--
Oğuz
Re: signals ignored in a subshell
Date:Sun, 5 Apr 2020 05:06:56 +0300 From:=?UTF-8?B?T8SfdXo=?= Message-ID: | I was expecting it to work (i.e interrupt read again and call foo) Isn't that what it did? But I see what you mean now, during the read that's called from the trap execution call of foo, SIGINT is blocked - that most probably should not happen, and it looks as if when the trap handler exits, the original read is resumed, that certainly shouldn't happen. Still, I don't believe that the way the function is written is a way that you can expect will work necessarily. kre
