Recent searches
Search options
got a lot of great answers to "how is the shell involved in handling Ctrl+C" to the effect of one of:
- "the shell is responsible for sending a SIGINT"
- "the shell takes input from the terminal emulator and relays it to the program"
- "it must be handled by the layer above the program, which is the shell"
and while none of those is true, they feel like they totally _could_ be true in a different world. It feels hard to explain why it might be useful to have a more "accurate" mental model
it feels like there's this mental model a lot of people have for the terminal which is a little like this (with some more stuff about signals etc)
and it's not "true" that the shell is in between the terminal emulator and programs in this way but it feels more compelling to me in some ways than the reality.
@b0rk What is the correct version? Is the shell at the same level as the (other) programs? Or is the shell a tiny bit special here?
@bartavi it's something like this but this diagram doesn't do a great job of describing the shell's role on its own (or what the terminal driver does)
@b0rk @bartavi i like this image more because it also shows that the foreground process is not necessarily a shell. It can be anything, like you can totaly start your prefered terminal emulator with ranger and you have a functional file browser, or with amixer/pulsemixer and you have your volume control "gui"...
it's like "every app is a web page" but terminal version
@bartavi @b0rk While I can't speak for Julia's perspective, mine is that the shell's primary interface with programs you run is _process control_ - creating process groups, forking new processes into them, executing programs in those forks, awaiting termination, and in some cases sending shell-originated signals to carry out job management.