^C / Ctrl-C closes REPL expression interpreter interactive loop

Hello,

I’ve noticed that the scala REPL is easily inadvertently closed by a Ctrl-C / ^C keystroke (I’m experiencing this under Linux, I don’t know if that’s true in other OS contexts), whereas usually in such command-line interpreter context, it’s commonly admitted that it should at most cancel current running operation or cancel inputting current command.

Would you please consider changing the behavior of the REPL (by installing or modifying an already existing SIGINT signal handler) and leave exit to ^D / Ctrl-D (under Linux) and other official commands (like :quit)?

I lost several times my experiments due to that unusual behavior, which is not so dissimilar to those dialog boxes with huge forms that close without warning when you hit escape. I always felt that such dialogs didn’t respect their users’ taken time to input data in numerous fields, only to see them vanish in a keyboard cat inadvertence.

Thanks. Regards,

1 Like

Or is there a means to reconfigure these key bindings and their associated behavior in some config file?

Are you using e.g. the Gnome Terminal? Then you can set Edit → Preferences → Shortcuts to have Copy and Paste assigned to Ctrl+C and Ctrl+V (and then the interrupt behavior is automatically assigned instead to the shortcut Shift+Ctrl+C). This is one of the first tweaks I do after a clean Ubuntu install :slight_smile:

I decided to edit my answer because one of my rereaders pointed out you might not be part of the scala development team


If indeed I’m using Ubuntu with Gnome and Gnome Terminal. The behavior I describe also happens with bash in a mere virtual console as well as a vanilla xterm.

The behavior of ^C under Linux normal circumstances is to trigger signal SIGINT which is meant to interrupt (well humanly speaking cancel) running programs under Linux (and all Unices since 1970).

Wiki quote from Signal (IPC) - Wikipedia
"
SIGINT

The SIGINT signal is sent to a process by its controlling terminal when a user wishes to interrupt the process. This is typically initiated by pressing Ctrl+C, but on some systems, the “delete” character or “break” key can be used.[13]
"

Your solution is to disable ^C altogether and remap it to something, solution that will only work in a terminal that allow such remapping.

If every time someone develops something for Linux or any other OS for that matter, something that has a behavior that is somehow cumbersome and asks their users to alter a common and very established functionality of the system it’s running on, here ^C, I think that the system will get messed up.

No, ^C is not a behavior specific to Gnome Terminal, it’s rather a very general Unix behavior.

Also no, this is not the fault of Gnome Terminal.

However, that a shell or program that behaves like a shell fails to handle SIGINT to provide a custom behavior more useful than ending up with the process killed, that is unusual. I’ve written such interpreters myself and this is really something I treat in the early stages of development so that I don’t kill my process every time I only wish to cancel current action within the interpreter, rather than cancelling the whole interpreter if you see my point. It’s common to emulate (is it?) the ^C behavior within a shell. Yes, is it? Indeed, bash for instance and ALL other shells do exactly that, otherwise they would get killed by the kernel as SIGINT’s default behavior is to do so.

As you might not be part of the scala dev team, I was merely asking them to consider installing a SIGINT handler (doc is here sigaction(2) - Linux manual page) as it’s common and even best practice in such a situation. Maybe I asked this question in the wrong place. My bad in that case.

Thanks in advance for considering this. With my best regards.

Now, reconsidering the location of this post, I’m not so sure to which bug tracker I should report this. Also, it’s more a feature request than an actual bug report. Could you please point out where this should be reported (if it should be reported as a bug in the first place)? Particularly, I’m not so sure it’s the scala or the sbt bug tracker. Thx in advance.

Regards.

You can report enhancement proposals and bugs here:

I think this seems worthwhile to report as an enhancement, perhaps as a setting or something.

I’m not sure how easy it is to implement this given the underlying jline library used. You can take a look at the code here if you are interested:

@som-snytt is one of the recent contributors to the REPL that might have insight into the SIGINT-handling stuff in jline (or might know who does).

I’m not part of the Scala dev team but I’m a happy participant in our community just like you :slight_smile: BTW: sincerely welcome!!

Also I guess this is a usability tradeoff; how to treat the prevailing idiom of Ctrl+C being copy clashing with SIGINT… But perhaps the behaviour of the REPL could at least be configurable…

True, but that can be said of every terminal on a system without a command button.

This might be opening up a can of worms, since the JVM likes handling signals itself (so you would have to load libjsig.so in order to chain signal handlers for Oracle JDKs AFAIK), there are differences between platforms and JVM implementations…

@tomoyo255 have you ever done this in Java, in a portable way?

Hello,

In a more jovial and maybe relaxed spirit, my article was simply to point out a possible enhancement to be made, not really to ask for help. I’m of course okay to discuss it, but I think it’s more a matter of whether or not you want this in your backlog, which is not my role. Indeed, my second message wasn’t my original intent, just a reaction to what’s been answered to me which I couldn’t help but answer to it because I felt we were beginning to miss the point here. This is why I explicitly mentioned signals, just to make my original statement clearer.

My remark about the best practice was simply to point out that it’s usually done this way, at least as far as I witnessed it.

Indeed, you have a point here. It may be more difficult to do that in the Java realm where the JVM is here to hide the real world to provide portability. However, that’s certainly a time where one cannot hide from the world: UNIX signals are a UNIX matter (and some other compatible OSes to some extent), that’s a fact that can’t be dodged. Now that you mention it, as an x86-ASM and C++ (with C++11+ templates) experienced developer (with some coq and functional programming powder), I haven’t got the chance to take this problem into consideration with Java, which could be a really exhilarating challenge if I had the time to do it. Maybe, you might find it as interesting as I may have and go for it and implement it and maybe come with a standard solution to do so for the programmer community. Would you? I think the ball is in your court now.

Best regards, good programming and most importantly: have fun!

FWIW the Ammonite REPL does support Ctrl-C interrupts: Ammonite

1 Like

Oh yes, they are using the sun.misc.Signal internal API to do that…

1 Like

I’ve just made an issue here on the coming new Scala 3 REPL:

Also @tomoyo255 it struck me that sbt seems to handle SIGINT so at least you don’t loose your sbt session as you can see in the issue example.

I just found this old issue and added a link there to this conversation in the comments: