Post AsDbGZPISCYvKtGHT6 by cks@mastodon.social
(DIR) More posts by cks@mastodon.social
(DIR) Post #AsCH3nUYaD6F0tOUs4 by b0rk@social.jvns.ca
2025-03-18T20:38:55Z
0 likes, 0 repeats
terminal poll: when you think about how `Ctrl+C` is handled in a unix terminal, who do you think is in charge of making that work? You can pick more than one.(not interested in the truth here, I know it's complicated, just curious about how people think about it)
(DIR) Post #AsCH3oqvWWaVEYrsNU by rozenglass@fedi.dreamscape.link
2025-03-19T01:22:55Z
0 likes, 0 repeats
@b0rk@jvns.ca As far as I understanding, the input of Ctrl+C will be received by the terminal, which uses a syscall to ask the kernel to send a signal to the whole tree of forked processes, starting with bash, and the child process (i.e. the program), and the program's children, etc. All of those processes optionally register their own signal handlers for SIGINT, and do whatever they want when they receive it including just ignoring it. I think bash just ignores it if it has a child program, but not sure. If the programs don't have a handler the default signal handler is used, which I think is registered at the start of the program, before main, by the libc runtime, but not sure. Hence, my vote would be all of the above, although the shell's involvement seems to be limited to just ignoring the signal, and the initial forking of the processes which allows them to receive the signal too.
(DIR) Post #AsCHupBR1ZTZbjjeYS by chrisamaphone@hci.social
2025-03-18T20:54:47Z
0 likes, 0 repeats
@b0rk whoa, “the program” is currently winning from what i see?? I felt like that was the only option i was confident about *not* including… are people really out there writing interrupt handlers in all their programs? or maybe they just mean the program *can* do this to override the default?
(DIR) Post #AsCHuqNsYn1ZKcZ6ae by uncanny_kate@dice.camp
2025-03-18T21:01:38Z
0 likes, 0 repeats
@chrisamaphone @b0rk I've absolutely written signal handlers in my code. For Ctrl-C (SIGINT), it's useful for doing some cleanup and exit, like closing a lockfile, writing to the log that it got the interrupt signal, and doing any data cleanup to leave it in a stable state.
(DIR) Post #AsCHurCvUzrDswRs9o by chrisamaphone@hci.social
2025-03-18T21:07:23Z
0 likes, 0 repeats
@b0rk @uncanny_kate ok, got it. so you’re thinking more in terms of augmenting default behavior with program-specific behavior… i guess one could interpret Julia’s phrase of “making that work” to apply to the spec for the program itself and not just correctness of SIGINT conforming to spec
(DIR) Post #AsCHus5WE1WgcFzTFY by rozenglass@fedi.dreamscape.link
2025-03-19T01:33:00Z
0 likes, 0 repeats
@b0rk@jvns.ca @uncanny_kate@dice.camp @chrisamaphone@hci.social The "default behavior", as far as I know, is also handled by the program, you just don't write it yourself most of the time, your program runtime does. In the case of C for example, it gets registered by the C runtime before it calls main(), in a Python program, it gets handled by the Python runtime, etc.
(DIR) Post #AsDbGYPGAqwGEUEjlw by b0rk@social.jvns.ca
2025-03-19T11:44:39Z
0 likes, 0 repeats
follow up: for folks who replied to "who's in charge of making Ctrl+C work in the terminal" with "the shell”, why did you say that?I'm much more interested in answers that you're not 100% sure about than "right" answers(also please don't correct people who say something you think is "wrong”)(2/?)
(DIR) Post #AsDbGZPISCYvKtGHT6 by cks@mastodon.social
2025-03-19T16:43:05Z
1 likes, 0 repeats
@b0rk I ticked off 'the shell' in my set of answers because of technical knowledge: a shell with readline handling is handling Ctrl+C itself when you're editing a command line. Many shells/readline environments will react to Ctrl+C this way by 'interrupting' the command line you're editing and giving you a new top level prompt (which is handy if eg you're writing a multi-line 'for' or 'while' or etc and change your mind; you can Ctrl+C to throw the entire thing away).
(DIR) Post #AsE9q7eiVTke8KbAeG by ShadSterling@mastodon.social
2025-03-19T13:35:02Z
1 likes, 0 repeats
@b0rk I wasn’t sure if “how ctrl+c is handled” meant “how ctrl+c becomes SIGINT” or “how the response to SIGINT is determined”; I checked “the shell” for the former. It works over SSH which AFAIK only sends keystrokes, so it can’t be the terminal emulator. Since AIUI the SSH tunnel goes to the stdin of the shell, I figured the shell is handling that input.But I’m not sure that’s right and I don’t know what the terminal driver is, is that between the emulator (or SSH) and the shell?
(DIR) Post #AsE9qCaeA2SzR9jUUy by ShadSterling@mastodon.social
2025-03-19T14:53:10Z
0 likes, 0 repeats
@b0rk wait, the ssh command won’t get ctrl+c in stdin, it’ll get SIGINT, so to send ctrl+c it would have to respond to SIGINT by sending ctrl+c, which… maybe it does that? Does ctrl+z also work over SSH? Maybe it uses some other API to bypass the usual handling and get everything in stdin?It’s not weird that I don’t know this, it’s weird that I never noticed there’s a thing there to know