fix(cli/repl): keyboard interrupt should continue

[caspervonb]

This changes the behavior of keyboard interrupts (ctrl+c) to continue, clearing the current line instead of exiting.

Exit can still be done with ctrl+d or by calling close().

[littledivy]

This seems to be the default behavior with Python, although Node does ask for confirmation.

[caspervonb]

This sounds really bad, ctrl+c means kill the process. It has always meant that. What is the point of this bizarre perversion of Unix?!

It means interrupt, SIGINT after all.

Anyway; based on prior art:

Bash clears and continues.
Python clears and continues.
Ruby clears and continues.
Node clears and continues (but does allow you to hit it again immediately to exit).

[ry]

Maybe print "exit using ctrl+d or close()" again on ^c ?

[nayeemrmn]

Note that the existing SIGINT behaviour still remains when an actual execution is interrupted:

[caspervonb]

Maybe print "exit using ctrl+d or close()" again on ^c ?

Since you phrased that as maybe, I think its a bit noisy, never liked Node doing it.
Prefer mimicking bash/zsh as a good examples of shells but I'll yield if anyone feels strongly about it.

Note that the existing SIGINT behaviour still remains when an actual execution is interrupted:

Been playing around with the new Runtime.terminateExecution method but that ends up killing the whole process which is somewhat unexpected.

[bartlomieju]

@nayeemrmn @caspervonb this is a long standing issue - #1725 - we need some kind of signal watchdog to implement that (I know tokio has APIs for that), and most likely tinker with deno_core to get it working.

[caspervonb]

@nayeemrmn @caspervonb this is a long standing issue - #1725 - we need some kind of signal watchdog to implement that (I know tokio has APIs for that), and most likely tinker with deno_core to get it working.

In this case we are catching the signal, it's just a matter of what do we do with it but research required so out of scope for this PR.

[bartlomieju]

Maybe print "exit using ctrl+d or close()" again on ^c ?

That sounds good to me, but I agree with @caspervonb that we should clear the input line on ^c.

[bartlomieju]

LGTM