What are the relations between control characters and signals? Or are they unrelated?

Are control characters received by a terminal?

After a terminal receives a control character, is the terminal sending out a signal to a process one of the possible action of the terminal to the received control character?

For example,

in Linux, in a terminal, Ctrl+C will terminate a running foreground process. In ASCII, Ctrl+C is a control character which means " End of Text".

In ASCII, Ctrl+D is a control character which means end of transmission. Does the control character make the terminal send out some signal to some process?

  • A control+c may or may not cause a running foreground process to terminate, depending on signal masking. The control+c will cause a SIGINT to be sent to all processes in the foreground process group (often including the shell, which means SIGINT handling in modern shells can be hilariously complicated). – thrig Mar 4 '16 at 0:12

The terminal driver (part of the operating system) establishes the relationship between special characters and signals. Your terminal settings, e.g., using stty, are what it uses to decide what (if anything) to do with characters that you type. You can reassign those special characters as needed with a few caveats:

  • only one special character per function
  • only single-byte characters are used

controlC and controlD are conventional: while a few applications may hardcode these values, the terminal driver does not require that.

The terminal driver is software, not part of your terminal. For some keyboards you may find different assignments of special characters more convenient than others (and for different operating systems, a few choices of the default values for the special characters may differ).

Further reading:

| improve this answer | |
  • Not necessarily any driver at all beyond what's used for an RS232 port when talking of control characters. Terminals are very easily bit banged. And not all terminals are emulated or have ncurses definitions in terminfo. – Wyatt8740 Mar 4 '16 at 4:13

Control characters and signals are sort of related. You can see what the match between signals and characters are with stty -a command in a terminal. A RHEL server I can access says:

-bash-3.2$ stty -a
speed 38400 baud; rows 24; columns 135; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -cdtrdsr
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Some of that is related to the TTY and what it does to input, other stuff to signals. The parts for signals:

intr = ^C; quit = ^\; susp = ^Z;

That means SIGINT is control-C, SIGQUIT is control-backslash and SIGSTOP is control-Z. You can reassign any or all of those, if you like. See man stty.

The other control characters like erase or werase are intercepted and used by the terminal driver itself. Like when you backspace, the terminal driver erases a character from the screen and from the input stream. The "mode" of the terminal driver (raw or cooked, possibly partially cooked) makes a difference as well. Text editors like vim and emacs make heavy use of control characters, and they don't get a SIGINT or SIGQUIT or whatever when you type those control characters. A program can set the TTY to "raw mode" and just read the bytes without interpretation by the terminal driver.

| improve this answer | |
  • 1
    i will never not be amused by the fact there's still a measurement of speed in baud – cat Mar 4 '16 at 3:11
  • 2
    baud is still used when controlling serial ports. Serial ports can have all sorts of stuff attached. – waltinator Mar 4 '16 at 3:42
  • 2
    @tac believe it or not, some of us still have serial terminals and actually need this. Pictured: a setup program that failed in xterm and emulated tty's and required a serial port terminal (the bug's been fixed, but they are valuable for debugging). Model IBM 3161 – Wyatt8740 Mar 4 '16 at 4:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.