Actually, that's not quite right. With pretty much all modern Unix systems, the kernel supports process groups, and the control-C gets sent to the tty's foreground process group. Since the shell will set up a new process group when it sets up a new command (or command pipeline) to be run, and then sets it to be the foreground process group, the shell never gets the signal, and isn't involved in forwarding the signal to the job. Instead the tty sends it directly to the command currently attached to the tty.
> All signals’ handling can be overridden except the SIGKILL.
... and SIGSTOP and SIGCONT.
SIGCONT can be handled just fine, both according to the manual, and in practice... (at least under Linux, been there, done that.)
Sure, but you cannot override or ignore the default action: that of continuing execution.
Not really that relevant, but it always sort of bugs me when people use the `kill` command with numbers instead of symbol names. I think it’s the programmer in me getting scared of “magic numbers”, but I find it much nicer to be able to write `kill -KILL <pid>` or `kill -HUP <pid>` than remembering all of the numbers.
Once you've used enough platforms, you get used to "kill -KILL <pid>", because "kill -9" doesn't work everywhere (being less standard), while the former is the POSIX way.