It's not the terminal emulators that send SIGINT/SIGQUIT/SIGTSTP, it's the terminal or pseudo-terminal device driver in the kernel that does.
Assuming it's configured with stty intr '^C'
for instance, when a ^C
character (0x3
byte) is received from the terminal over a serial connection or from a terminal emulator from the master side of the pseudo-terminal, the kernel sends the SIGINT signal to all the processes in the foreground process group of the tty device (and it's your interactive shell that decides which is the foreground process group at any given time).
On Linux at least there's no equivalent terminal driver (termios) setting for mapping a character to a SIGKILL signal sent to the foreground process group.
The xterm
terminal emulator can be configured to send some signals including SIGKILL with the send-signal(kill)
action upon some X11 event (such as KeyPress events)
xterm -xrm 'XTerm.VT100.translations: #override Ctrl <Key>k: send-signal(kill)'
For instance would start an xterm
that sends SIGKILL upon Ctrl+k.
In the default menu that you get with Ctrl + MouseButton1, you can do the same with the Send KILL Signal
entry.
However, it sends it to the process group that it created itself typically to run your shell, not the foreground process group of the slave terminal device. So it will likely not do what you want.
Even if you found a way for the terminal emulator to send SIGKILL to the foreground process group, first it would not be able to do it if the processes were running as a different uid, but also it would not do what you want if for instance you started a ssh
/ script
/ screen
... session in it, as it would then need to send the signal to the foreground process group of their tty device.