5 Nisan 2020 Pazar tarihinde Robert Elz <k...@munnari.oz.au> yazdı: > Date: Sun, 5 Apr 2020 05:06:56 +0300 > From: =?UTF-8?B?T8SfdXo=?= <oguzismailuy...@gmail.com> > Message-ID: <CAH7i3Lr5TTK+N-qC39+nmSo7jjhzDvPux39N4i2MyP5LCnnv5 > w...@mail.gmail.com> > > | I was expecting it to work (i.e interrupt read again and call foo) > > Isn't that what it did?
No, it ignored/blocked 2nd SIGINT . > 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. > > Exactly. In my opinion, read should behave the way wait does: fail upon a signal for which a trap is set, and return a non-zero value when handler returns. Don't really know how hard it would be to implement that though. I cloned and compiled bash's devel branch and tested this on it. It keeps printing a warning message upon every SIGINT (but doesn't ignore them). > Still, I don't believe that the way the function is written is a way > that you can expect will work necessarily. > > That function is a simplified version of a script posted here: https://stackoverflow.com/questions/61023171/bash-trap-sigint-multiple-times-doesnt-work > kre > > -- Oğuz
