When a shell runs a builtin, and a signal is generated by keyboard, what will handle the signal?

Question

Please correct me if I am wrong: When a bash shell runs an external executable program, the bash shell will create a child process to run the program in foreground. If there is any key-generated signal, the signal will be sent to the child process and handled by program.

When a bash shell runs a builtin command, the bash shell will run the builtin command in the shell process directly in foreground. If there is any key-generated signal, will the signal be sent to the shell process? Which will handle the signal, the builtin command's program or bash? Can a builtin command have its own signal handler, or does it have to rely on the signal handlers of bash?

For example, when a bash shell is running wait in foreground and I press Ctrl-C, will the signal SIGINT be received by the shell process and handled by wait or by bash? Does wait have its own signal handler or rely on the signal handler of bash?

Thanks.

Answer 1

Which will handle the signal, the builtin command's program or bash?

The builtin command's program is bash. That's the definition of a builtin: it's built into the shell, it isn't an external program.

The shell might react differently depending on what it's doing when it receives a signal. But it's always the shell process that receives the signal, since there's no other process involved.

Answer 2

The easiest way to understand Linux terminal devices (/dev/tty*, /dev/pts/*) is if you think of them as streaming sockets. As if the /dev/tty12 would be a TCP port, like 127.0.0.1:8080.

Processes are connecting to them, get input from them, write into them, and then finally disconnect from them. A socket (terminal) can have a connection with multiple processes.

Other processes can listen on them, they are typically the terminal emulator programs, but not always. In the case of the character terminals, the Linux kernel itself works as a "listener daemon" on the terminal device.

The "extra feature" that a terminal has, but a socket hasn't: the kernel keeps track of which processes are connected to it, and it is capable to signal them on need. It so happens if, for example, you press Ctrl+c.

You can read a detailed list of the signals passed there answer.

What exactly happens if you press Ctrl+c?

It is not as if somebody presses a normal button, for example, an a key. In this case, the pressed key is simply written into the terminal device and can be read out by the processes reading from it (which is typically the process in the foreground).

In the case of special keypresses, for example, Ctrl+z, or when you close/resize the terminal window, and so on, the terminal gets the request and the kernel sends to all processes attached to it the corresponding signal. To all of them, it will be later important later.

These devices can be also controlled by well-directed ioctl() calls.

If bash runs a subprocess (i.e. external command), then the following happens:

1. bash starts the process in the background, giving to it the terminal
2. bash stops getting input from the terminal
3. after the process stops, bash sets everything back.

However, the bash still remains attached to the terminal device, and if a Ctrl+c is coming, it will get the signal. Also the external command will get the signal.

However, these signals can be overridden (signal(), sigaction() system calls). Bash overrides them, i.e. it overrides the default signal handling routine (which would simply stop it) with its own. This is why it doesn't exit if you press the Ctrl+c in a command prompt.

However, a sleep 60 will exit. It doesn't change its signal handlers.

If you run a bash internal command, this signal handler will work as you said (it stops the internal command execution and gets you back to the prompt).