Before explaining out your problem, a bit of context on how read command works. It reads in input data from stdin until EOF is encountered. It is safe to say the call to read command is non-blocking when it comes to reading from on-disk files. But when stdin is connected to the terminal, the command will block until the user types something.
How signal handlers work?
A simple explanation on how signal handling works. See the below snippet in C which just acts on SIGINT ( aka. CTRL+C)
#include <stdio.h>
#include <signal.h>
/* signal handler definition */
void signal_handler(int signum){
printf("Hello World!\n");
}
int main(){
//Handle SIGINT with a signal handler
signal(SIGINT, signal_handler);
//loop forever!
while(1);
}
It will register the signal handler and then will enter the infinite loop. When we hit Ctrl-C, we can all agree that the signal handler signal_handler() should execute and "Hello World!" prints to the screen, but the program was in an infinite loop. In order to print "Hello World!" it must have been the case that it broke the loop to execute the signal handler, right? So it should exit the loop as well as the program. Let's see:
gcc -Wall -o sighdl.o signal.c
./sighdl.o
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
^CHello World!
As the output indicates, every time we issued Ctrl-C, "Hello World!" prints, but the program returns to the infinite loop. It is only after issuing a SIGQUIT signal with Ctrl-\ did the program actually exit. Depending on your ulimit settings, it would dump a core or print out the signal number received.
While the interpretation that the loop would exit is reasonable, it doesn't consider the primary reason for signal handling, that is, asynchronous event handling. That means the signal handler acts out of the standard flow of the control of the program; in fact, the whole program is saved within a context, and a new context is created just for the signal handler to execute in. Once the signal handler has completed its actions, the context is switched back and the normal execution flow starts (i.e. the while(1)).
To answer your questions,
The conclusion verified that When bash is executing an external command in the foreground, it does not handle any signals received until the foreground process terminates
The key thing to note here is the external command part. In the first case, where sleep is an external process but in the second case, read is a built-in from the shell itself. So the propagation of the signal to these two differs in both these cases
type read
read is a shell builtin
type sleep
sleep is /usr/bin/sleep
1.Open a terminal,named termA ,and run the created file callback.sh with /bin/bash callback.sh for first time,the info pop up instantly.
Yes, this behavior is expected. Because at this time only the function is defined and the trap handler is registered to the function myCallback and the signal is not yet received in the script. As the execution sequence goes, the message from the read prompt is thrown for the first time.
2.Open a new terminal ,named termB and run pkill -USR1 -f callback.sh first time,the info pop up instantly in termA
Yes, while the read command is waiting for string followed by the Enter key pres which signals the EOF, it receives a signal SIGUSR1 from the other terminal, the current execution context is saved and the control is switched the signal handler which prints the string with the current date.
As soon as the handler finishes executing, the context resumes to the while loop in which the read command is still waiting for an input string. Until the read command is successful, all subsequent signal traps would just print the string inside the signal handler.
Go on in termB,run pkill -USR1 -f callback.sh the second time.
Same as explained previously, the read command is not complete for once in your while loop, only if it is successful reading a string, the next iteration of the loop would start and a new prompt message would be thrown.
Image source: The Linux Programming Interface by Michael KerrisK
