Let me be clear: Don't kill the program (e.g. by sending SIGINT to the program) and then complain that the rest of the program (e.g. the signal handler) doesn't run.

Don't kill the program (e.g. by sending SIGINT to the program) and then complain that the rest of the program (e.g. the signal handler) doesn't run.

I didn't.

$ perl -e 'sleep 10;print"World\n"' | perl -e '$x=time;
    $SIG{ALRM}=sub{print"Hello ";$y=time}; alarm 2;
    $z=<>; print $z,$y-$x," ",time-$x,"\n"'
Hello World
2 10
[download]

On my system, all of the above output does not happen until after 10 seconds. See above.

Funny discussion. But I think both of you are correct.

When blocking the program with <>, is the alarm signal block executed when I send SIGINT? On Unix/Linux: In case waited long enough for the alarm timeout to happen: Yes, always.

So why is it not printed? A buffering issue? Yes and no.

Yes and no?

Yes, data may be stuck in the buffer when using STDOUT (e.g. it did not have a "\n" when that was the flush condition). But that is not the reason why it is not printed.

Sigh..., so why is it not printed then?

Because the program received a SIGINT and terminated because the program does not have a handler. Remind that the intention of SIGINT is to provide a mechanism for an orderly, graceful shutdown. But the program doesn't have that so it has ended prematurely and the buffer is not flushed at normal program end.

But why is the line ending with a '\n' printed then after sending the SIGINT? Because the line was already transferred to the operating system buffer. But that buffer was only flushed after the blocking <> was terminated.

This is how I think it works and why I think you are both right. However not entirely explained correctly maybe.

I didn't.

Don't lie. Your own output showed you used Ctrl-C.

all of the above output does not happen until after 10 seconds

This was already explained.