Thanks for the reply.
4 Nisan 2020 Cumartesi tarihinde Robert Elz <k...@munnari.oz.au> yazdı:
> Date: Sat, 4 Apr 2020 08:32:57 +0300
> From: =?UTF-8?B?T8SfdXo=?= <oguzismailuy...@gmail.com>
> Message-ID: <CAH7i3LqUZcV6shJv6nQoRkLp-zhBgTpWaUPKdzZwVC-W_0e8yw@
> 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
