Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ctrl-C

kevinlawler.com

Post reply on HN
Print view View original

61–70 of 94 posts

Re: Ctrl-C

#61

Post by codethief »

klez wrote: post #16
codethief wrote: post #9

> We don't want our ctrl-c to leak memory. […] If you allocate a piece of memory, you need to store a pointer to that memory from the object graph, and both of those operations need to occur inside of a critical section. Otherwise, if you get interrupted right after the allocation, there won't be any way to reach your memory and it will leak. Maybe I'm missing something here but… so what? If at the end of your Ctrl+C…

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).

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.

Re: Ctrl-C

#62

Post by zokier »

gfodor wrote: post #56
klez wrote: post #16

Earlier quoted context omitted.

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).

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.

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=32367401

Re: Ctrl-C

#63

Post by taf2 »

I prefer when programs listen for SIGQUIT… it makes more sense that this would be used to quit a process then SIGINT - IMO …

Re: Ctrl-C

#64

Post by klez »

codethief wrote: post #61
klez wrote: post #16

Earlier quoted context omitted.

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).

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.

I suggest you tell this to the author, not to me :P

Re: Ctrl-C

#65

Post by dgfitz »

vermilingua wrote: post #46
dgfitz wrote: post #30

Earlier quoted context omitted.

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.

> 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.

Agreed. Not sure what your point is.

Re: Ctrl-C

#66

Post by hnlmorg »

klez wrote: post #51
M9HF8wwiaAdZKEZ wrote: post #43

Earlier quoted context omitted.

> 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 key…

> 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…

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’.

Re: Ctrl-C

#67

Post by [deleted] »

ghoward wrote: post #32

Surprisingly, it is possible to do exactly what the author wants. I know because I've done it. However, it is as complicated as the author says it is. The project in question is my `bc` [1]. Until version 3.0.0 [2], it used a "yield" architecture: every loop it could enter had a check for a signal. This got tedious, so I decided to make the jump to instant-ish reset. I was lucky in several ways. First, `bc` is a real…

[deleted]

Re: Ctrl-C

#68

Post by klez »

hnlmorg wrote: post #66
klez wrote: post #51

Earlier quoted context omitted.

> 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…

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 li…

> or they capture ^c and interpret it to behave like the classic shells do because that’s the behaviour people expect from shells.

Which is kinda the point.

> So literally every ‘if’, ‘echo’ and ‘for’ (etc) has its own process ID in Linux/UNIX. Thus you can ‘kill’ an ‘echo’.

Do they? Because if I try like this `while :; do echo; done` and in another terminal I do `ps -x --forest` I can see the original bash running but it doesn't have any child process.

Besides, is it relevant to the discussion at hand?

Re: Ctrl-C

#69

Post by emmelaich »

jesprenj wrote: post #60

Even though it makes sense from the name, SIGINT, to interrupt, I've rarely seen console software "return control" to the user when the signal is received. What I've mostly seen in programs is a clean exit from the running application, if live user input is not intended to be used. Clearing a line or something similar like redrawing the terminal (that's mostly Ctrl-L though) is what interactive programs do, let's say…

REPLs for one.
Post reply on HN