I don't know exactly if the terminal is the handler of keystrokes like CTRL + C or CTRL + D and many others or the shell.

When I press a keystoke I think about it this way, as the picture describes:

enter image description here

When a keystroke is pressed, the keystrokes is handled by the shell, the shell interprets the keystrokes and do whatever it needs to do, perhaps sending a signal when CTRL + C is pressed or clearing the screen with CTRL + L and so on. Therefore, the shell plays the role of the middle-man for the program's inputs. Inputs go from shell to the program's stdin.

The program's stdout goes to the shell, and the shell redirects the output to a terminal or files or pipes.

The terminal sends the shell the bytes of the pressed keys.

Am I right?

  • I'd guess: The terminal first, then probably the (psuedo-)TTY and last the shell, since the terminal needs to handle shortcuts configured for it. See last section of Gilles' answer.
    – muru
    Jun 19 '17 at 11:47
  • I don't know why this question is marked as duplicate, because I've read that question several times before. And my question doesn't seem to relate to distinction between terminals and shells.
    – direprobs
    Jun 19 '17 at 12:13
  • 1
    You have read it several times and completely missed the last section of Gilles' answer?
    – muru
    Jun 19 '17 at 12:14
  • @muru I'll have a look at it again.
    – direprobs
    Jun 19 '17 at 12:19
  • 1
    unix.stackexchange.com/questions/4126/… only addresses this superficially. unix.stackexchange.com/questions/116629/… goes into much more detail. Jun 20 '17 at 22:26

Not really. Signals etc are handled by the terminal driver, so the shell doesn't really know whether you typed a literal ctrl-C or sent it the same signal with kill from another window, for example.

Keystrokes -> Terminal -> Terminal driver -> Foreground process

When the shell isn't the foreground process (such as when you used it to start an interactive program, or really any foreground process at all), that program receives keyboard input and any signals from the terminal driver.

Standard input comes from the terminal by default, but you could run a shell with its input redirected from a file or a network stream, for example, and the shell doesn't really know the difference. Similarly, the shell can redirect standard input, output, and error streams for its child processes irrespectively of whether a terminal is involved at all.

  • Actually, one of the criticisms against the legacy C shell is that it failed to properly decouple the terminal from standard input.
    – tripleee
    Jun 19 '17 at 11:50
  • Part of the problem is that, since I'm from a new generation I've never seen a terminal in my life which makes the distinction difficult to see. So basically that's to say, if the shell is the foreground process, then it receives signals from the terminal drivers. In other words, key strokes are handled by the terminal or specifically by (the terminal driver). Right?
    – direprobs
    Jun 19 '17 at 12:12
  • And in terms of terminal (physical hardware) not terminal emulators, is the story the same as well? I'm wondering
    – direprobs
    Jun 19 '17 at 12:14
  • 2
    Pretty much, yeah. Once upon a time, if a new terminal with a special break key was introduced, for example, the manufacturer would create (or at least hope that somebody created) a new terminal driver which supported that key. Emulators by definition talk to an existing driver (they emulate a hardware device for which the driver was once created) but that also means they are kind of stuck in the 1970s.
    – tripleee
    Jun 19 '17 at 12:25

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