Ctrl-c doesn't seem to work in web terminal

[praveen-srinivasan]

This is Jupyter notebook server 4.1.0

Ctrl-c doesn't seem to do what I would expect, e.g. if I do something like "tail -f foo" and then hit "ctrl-c", it doesn't exit "tail". It just prints "^C" on the screen.

[takluyver]

Works for me. What OS & browser are you on?

[praveen-srinivasan]

Mac OS X, Chrome (also doesn't work in Safari)

[yuvipanda]

Same as #104 I think?

[takluyver]

I think #104 is about copy/paste, and this is about interrupting programs using Ctrl-C. Both are likely terminado issues rather than something we can fix, though there's a small chance that this is something on our side.

[alouisos]

Reporting the same issue on Mac OS Chrome terminals. Cannot interrupt process in terminal with Ctrl+C

[kingjr]

Same problem with with Ubuntu 14.04 & Firefox.

[gnestor]

I have verified that ^C is successfully interrupting a process using Chrome on OS X.

Screenshot:

[ricardobarroslourenco]

I'm under the same issue, using MacOS El Capitan...

[oolongknits]

I had the same problem and (at least in my case) this is a problem with the terminal shortcuts.

I'm on Linux and in the terminal I did:
Edit -> Preferences -> Shortcuts
I found Ctr+C was a shortcut to Copy.
I changed it to something else and now it works as it is supposed to.

[oschuett]

Maybe the Jupyter terminal should overwrite some of the browser's default shortcuts:
https://stackoverflow.com/questions/3680919/overriding-browsers-keyboard-shortcuts

[gnestor]

I should add that it's working for me using Chrome on MacOS Sierra.

I understand that CTRL+C on Windows is copy and I don't think there is anything we can do to override that, but I'm curious what shortcut do you use to kill a process in the Window's terminal? Linux?

[oschuett]

I'm using Chrome under Linux and there it's not working either for the same reason. Hence, my proposal to prevent the default event handling in these cases.

[gnestor]

But what if you want to copy something from the terminal output?

[takluyver]

On Linux, GUI Ctrl shortcuts typically become Ctrl-Shift in a terminal - Ctrl-Shift-C for copy, Ctrl-Shift-N for new window. It's up to the terminal emulator, though. That leaves shortcuts like Ctrl-C for sending control characters to the terminal (which the pty may then translate into signals, e.g. SIGINT).

The default command prompt in Windows doesn't have shortcuts for things like 'copy', as far as I know - you have to initiate copying with the mouse. I'm not sure what other Windows terminal emulators do.

[gnestor]

@takluyver Any ideas on how to resolve this for Windows users?

[takluyver]

Resolve what? It should work the same for users running the browser in Windows against a Unix server, and the terminal isn't supported when the server runs on Windows.

[gnestor]

Ok, I wasn't sure if the terminal is the notebook was working as expected or not. So nothing needs to be done then?

[takluyver]

It sounds like there is a problem for some people, but it's not clear under what conditions it occurs.

The behaviour I'd expect in a terminal is:

1. Ctrl-C is delivered to the terminal, where it will typically be translated into SIGINT.
2. If the frontend (terminal emulator) is in Linux or Windows, Ctrl-Shift-C copies to the clipboard.
3. Other platform copy shortcuts, such as Cmd-C on OS X and Ctrl-Insert on Linux, should work as normal.

Browser limitations may prevent us from implementing 2, because we can only access the clipboard when the browser's own mechanisms handle a clipboard shortcut. But it sounds like there are some problems with 1.

This is probably an issue with xterm.js, and it may already be fixed, either in a version we've already bundled into Jupyter since it was reported, or a still newer version. But without a reliable way to reproduce it, we don't really know.

[gnestor]

Ok, thanks for breaking this down, @takluyver. I guess it wouldn't hurt to bump our xterm.js dependency in the notebook. I'll do that now....

I took a look at the xterm repo and there doesn't seem to be any outstanding issues or recently submitted PRs regarding using CTRL-C or SIGINT, but there was Fix Ctrl+Shift+V pasting.

[rjurney]

This still exists and is not fixed. This is a serious problem for me... I can't have students exit their Flask Python programs they run in terminals. CTRL-Z works, CTRL-C does nothing but print '^C'. I am on OS X in Chrome. It also happens in Firefox and Safari.

Does anyone have ideas? I could even try to fix this if someone can tell me what needs fixing.

[dhirschfeld]

On Windows Ctrl-Break is often used for terminating processes, but so is Ctrl-C

[takluyver]

Unfortunately we haven't figured out what needs fixing - we can't reproduce the problem, so it's hard to investigate.

Now that terminals are supported when Windows is on the backend as well, there may be a bug there.

If you can reproduce the problem, can you try:

• Run python3 -c "import time; time.sleep(10)" in the terminal, and try Ctrl-C while that is running. This is a simple baseline to check whether the problem is with the terminal or the process. If you get a KeyboardInterrupt, then the terminal is working as we expect, and problems with other programs are up to those programs.
• If you're running on Windows, can you also try it with the browser in Windows and the server on Linux (e.g. using https://mybinder.org/v2/gh/ipython/ipython-in-depth/master ).
• Try with different browsers - anything related to keyboard shortcuts is often browser specific.

[liucimin]

This still exists and is not fixed.

[lleeoo]

I've found a way to rep both the correct and the incorrect behaviour.

Exec summary

Ctrl+C fails when I start jupyter remotely via ssh.

Versions

Jupyter 6.0.3, Python 3.7.7, RHEL 6 or 7.

Details

If I ssh to the server directly, run jupyter, then log out, Ctrl+C interrupts programs:

nohup "jupyter notebook --no-browser" < /dev/null > $remote_tmp_file 2>&1 &

However, if I try executing the exact same command from my machine, via ssh -q then Ctrl+C doesn't work:

ssh -q "nohup jupyter notebook --no-browser < /dev/null > $remote_tmp_file 2>&1 &"

AFAIK everything else works. stty -a is identical.

I have to try now with tmux to see if there is a way to retain the remote start functionality.

[AlexGuo1998]

However, if I try executing the exact same command from my machine, via ssh -q then Ctrl+C doesn't work:

ssh -q "nohup jupyter notebook --no-browser < /dev/null > $remote_tmp_file 2>&1 &"

It's even easier to reproduce. Create run.sh as below:

#!/bin/sh
nohup jupyter notebook >jupyter.log 2>&1 &

Remember to chmod u+x run.sh

Now try:

./run.sh

... and Ctrl-C is broken in terminal

Alternatively, kill previous notebook and try:

source ./run.sh

... then Ctrl-C works correctly!

[cwindolf]

Possible workaround: ^C works for me inside tmux in the Jupyter web terminal (but not without tmux). My probably outdated versions are:

$ jupyter --version
Selected Jupyter core packages...
IPython          : 8.28.0
ipykernel        : 6.29.5
ipywidgets       : 8.1.5
jupyter_client   : 8.6.3
jupyter_core     : 5.7.2
jupyter_server   : 2.14.2
jupyterlab       : 4.2.5
nbclient         : 0.10.0
nbconvert        : 7.16.4
nbformat         : 5.10.4
notebook         : 7.2.2
qtconsole        : not installed
traitlets        : 5.14.3

(I'm running the terminal in Lab, but couldn't find a similar issue on that repo.)