5 ms·

That's the point: Ctrl-C shouldn't just gracefully kill the process, it should interrupt the current computation and let you resume your work without exiting th

by klez 4y ago

That's the point: Ctrl-C shouldn't just gracefully kill the process, it should interrupt the current computation and let you resume your work without exiting the application. The use case here is interactive applications (think a REPL, for example), not commands you run, simply expect an output from and then they just exit (like, say, curl).

dgfitz 4y ago
IMHO anyone launching an app via a terminal and Ctrl-C killing it either is developing the app (in which case they can manage the signal however they like) or they don’t care and just want the app to die. Any “good” repl won’t let you exit via Ctrl-C so that point is moot.
- vermilingua 4y ago
  > Any “good” repl won’t let you exit via Ctrl-C And in order to achieve that, it has to take the care described in TFA.
  - dgfitz 4y ago
    Agreed. Not sure what your point is.
M9HF8wwiaAdZKEZ 4y ago
> it should interrupt the current computation and let you resume your work without exiting the application That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. If you want to be able to "resume your work" then you should press Ctrl+Z. If you want something else then the application should probably be listening for some other keystroke. "Catch Ctrl+C and do something else" is a pretty awful idea for the very reason mentioned at the top of TFA (when you press Ctrl+C, it's to get out of whatever you're stuck in, so that you don't have to go open another terminal and type in killall ...)
- macleginn 4y ago
  > That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. I spend a lot of time running computations in REPL, and sometimes I realise that I made a mistake and I don't want to wait for the current operation to complete, or the mistake itself is such that the operation will complete only after I become old and die. In this case, I expect Ctrl+C to abort the current computation and return to the REPL, with the previous state (all the variable assignments) intact (modulo assignments made inside the loop I killed). I think a lot of people have the same expectation, and it's usually satisfied in modern REPLs.
- duped 4y ago
  If the application is a shell or REPL (an application running other programs) then that is exactly what you want to use CTRL-C for.
- klez 4y ago
  > That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. If that's not how it should behave, how come any REPL I have handy handles Ctrl-C the exact same way? i.e. it doesn't exit the interpreter, it gets me back to the REPL. You can try yourself by getting stuck in a while loop and pressing Ctrl-C Python (3) does it; jshell does it; guile does it; csi (chicken scheme) does it; sbcl does it; bash does it
  - hnlmorg 4y ago
    Because they either fork their processes so the running task is it’s own process (which is how classic shells, like Bash, work) or they capture ^c and interpret it to behave like the classic shells do because that’s the behaviour people expect from shells. You have to remember that Bash isn’t a language like Python in the sense that it’s core libraries are built into the Python runtime. in classic shells like bash literally every command is an executable. Granted they’ll ship some “builtins” but they’re still invoked via fork() to behave like external commands. So literally every ‘if’, ‘echo’ and ‘for’ (etc) has its own process ID in Linux/UNIX. Thus you can ‘kill’ an ‘echo’.
gfodor 4y ago
The article’s point is basically proven by how many people here don’t even understand he’s talking about this, and not killing the program with Ctrl-C.
- zokier 4y ago
  Rather the opposite; people have hard time understanding what he is talking about because most applications that people use already handle ctrl-c as author wants, so its not a problem many people encounter often. So its reasonable that people then think its talking about the problem that many are encountering, programs that just swallow ctrl-c without doing anything. This is not helped by author having this bit near the beginning: > More often than not I find myself having to kill the running process from an external app, such as the shell, after first figuring out what the process ID is. See for example these sibling threads: https://news.ycombinator.com/item?id=32369096 https://news.ycombinator.com/item?id=32369096 https://news.ycombinator.com/item?id=32367401 https://news.ycombinator.com/item?id=32367401
  - gfodor 4y ago
    Well maybe then it only proves people don’t read the articles they comment on :)
codethief 4y ago
You don't mention REPLs etc. until the very end of the article: > It definitely applies to interpreters, database-style terminal interfaces, REPLs, consoles, calculators, command-lines, and other categories I've unintentionally left out. So if your article is supposed to be exclusively about those, I'd suggest you make this clear right in the beginning.
- klez 4y ago
  I suggest you tell this to the author, not to me :P
  - codethief 4y ago
    Oops, sorry, I confused you with kcl. :)

by klez 4y ago

dgfitz 4y ago

IMHO anyone launching an app via a terminal and Ctrl-C killing it either is developing the app (in which case they can manage the signal however they like) or they don’t care and just want the app to die. Any “good” repl won’t let you exit via Ctrl-C so that point is moot.

vermilingua 4y ago
> Any “good” repl won’t let you exit via Ctrl-C And in order to achieve that, it has to take the care described in TFA.
- dgfitz 4y ago
  Agreed. Not sure what your point is.

M9HF8wwiaAdZKEZ 4y ago

> it should interrupt the current computation and let you resume your work without exiting the application That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. If you want to be able to "resume your work" then you should press Ctrl+Z. If you want something else then the application should probably be listening for some other keystroke. "Catch Ctrl+C and do something else" is a pretty awful idea for the very reason mentioned at the top of TFA (when you press Ctrl+C, it's to get out of whatever you're stuck in, so that you don't have to go open another terminal and type in killall ...)

macleginn 4y ago
> That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. I spend a lot of time running computations in REPL, and sometimes I realise that I made a mistake and I don't want to wait for the current operation to complete, or the mistake itself is such that the operation will complete only after I become old and die. In this case, I expect Ctrl+C to abort the current computation and return to the REPL, with the previous state (all the variable assignments) intact (modulo assignments made inside the loop I killed). I think a lot of people have the same expectation, and it's usually satisfied in modern REPLs.
duped 4y ago
If the application is a shell or REPL (an application running other programs) then that is exactly what you want to use CTRL-C for.
klez 4y ago
> That's not what Ctrl+C is meant for or used for. It's used to terminate the running application, not the running task within that application. If that's not how it should behave, how come any REPL I have handy handles Ctrl-C the exact same way? i.e. it doesn't exit the interpreter, it gets me back to the REPL. You can try yourself by getting stuck in a while loop and pressing Ctrl-C Python (3) does it; jshell does it; guile does it; csi (chicken scheme) does it; sbcl does it; bash does it
- hnlmorg 4y ago
  Because they either fork their processes so the running task is it’s own process (which is how classic shells, like Bash, work) or they capture ^c and interpret it to behave like the classic shells do because that’s the behaviour people expect from shells. You have to remember that Bash isn’t a language like Python in the sense that it’s core libraries are built into the Python runtime. in classic shells like bash literally every command is an executable. Granted they’ll ship some “builtins” but they’re still invoked via fork() to behave like external commands. So literally every ‘if’, ‘echo’ and ‘for’ (etc) has its own process ID in Linux/UNIX. Thus you can ‘kill’ an ‘echo’.

gfodor 4y ago

The article’s point is basically proven by how many people here don’t even understand he’s talking about this, and not killing the program with Ctrl-C.

zokier 4y ago
Rather the opposite; people have hard time understanding what he is talking about because most applications that people use already handle ctrl-c as author wants, so its not a problem many people encounter often. So its reasonable that people then think its talking about the problem that many are encountering, programs that just swallow ctrl-c without doing anything. This is not helped by author having this bit near the beginning: > More often than not I find myself having to kill the running process from an external app, such as the shell, after first figuring out what the process ID is. See for example these sibling threads: https://news.ycombinator.com/item?id=32369096 https://news.ycombinator.com/item?id=32369096 https://news.ycombinator.com/item?id=32367401 https://news.ycombinator.com/item?id=32367401
- gfodor 4y ago
  Well maybe then it only proves people don’t read the articles they comment on :)

codethief 4y ago

You don't mention REPLs etc. until the very end of the article: > It definitely applies to interpreters, database-style terminal interfaces, REPLs, consoles, calculators, command-lines, and other categories I've unintentionally left out. So if your article is supposed to be exclusively about those, I'd suggest you make this clear right in the beginning.

klez 4y ago
I suggest you tell this to the author, not to me :P
- codethief 4y ago
  Oops, sorry, I confused you with kcl. :)