0

I'm trying to figure out how exactly CTRL^C sends a SIGINT to a process. Let's consider a pseudo-terminal system. I'll write what I know (or think I know lol) and please add/replace where needed:

The players are:

  • Xterm - This is a user space program that reads from the keyboard (using the X window system) and renders a picture to the screen. Every character it gets from the keyboard is passed to the pty master .
  • User process - the user process that runs as a foreground job of the terminal. Usually when opening a Xterm it runs bash or some other shell program as this user process.
  • PTY device - This is a character device that the user process is connected to as its stdin, stdout, stderr. Everything that's written by the process to stdout is processed by the TTY driver and its line discipline, and passed as input to the maser side, and vice versa.

I don't mind at the moment how exactly the kernel passes the signal to the process once the line discipline/TTY driver understands that it should send such a signal to the process. What I'm interested in is how, after I press CTRL^Z on my keyboard, the Xterm (Which is the process that reads this key presses) passes this information to the pty master

EDIT

Thanks for the answers. I welcome you to response on this thread where I actually tried to simulate this by writing 0x3 to a PTY master and see what happens in the slave. Could you guys respond to that?

Improve this question

1 Answer 1

Reset to default
1

xterm just writes the ^C character (ASCII 3) to the pseudo-tty master, something you can easily simulate with script (another program which, just like xterm, is managing a master pseudo-tty):

{ sleep 1; printf '\x03'; } | script -qc 'trap "echo SIGINT ma tuer; exit 1" I
NT; cat' /dev/null
^CSIGINT ma tuer
Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .