Ctrl+C never terminates Jupyter Lab running on Git Bash.

[jaepil-choi]

• I was not able to find an open or closed issue matching what I'm seeing

#1470 Seems like a similar problem but it was closed due to inactivity, not by a solution/fix.

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.25.0.windows.1
cpu: x86_64
built from commit: 7c71c859c97853ed057da5cbab12f3c13b5554df
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Windows 10 pro, 64bit.

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.18363.535]
(c) 2019 Microsoft Corporation. All rights reserved.

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VisualStudioCode
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

I'm running jupyter lab on top of poetry virtual environment. I'm doing all that in Git Bash.

Also, I just updated Git for Windows.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Git Bash for Windows

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

$ jupyter lab
(More specifically, $ poetry run jupyter lab but I don't think this makes any significant difference.)

Then it will run Jupyter Lab instance that keeps running on the terminal until it gets killed, like this:

Jaepil@Jaepil-PC MINGW64 /e/VSCodeProjects/finance_essentials_37-64
$ poetry run jupyter lab
[I 02:55:09.459 LabApp] JupyterLab extension loaded from c:\users\jaepil\appdata\local\pypoetry\cache\virtualenvs\finance-essentials-37-64-scqrhb_n-py3.7\lib\site-packages\jupyterlab
[I 02:55:09.459 LabApp] JupyterLab application directory is c:\users\jaepil\appdata\local\pypoetry\cache\virtualenvs\finance-essentials-37-64-scqrhb_n-py3.7\share\jupyter\lab
[I 02:55:10.045 LabApp] Serving notebooks from local directory: E:\VSCodeProjects\finance_essentials_37-64
[I 02:55:10.045 LabApp] The Jupyter Notebook is running at:
[I 02:55:10.045 LabApp] http://localhost:8888/?token=4c6b4ca60c6184c957aca9e6fc8e1335a56ea051fa450eb2
[I 02:55:10.045 LabApp]  or http://127.0.0.1:8888/?token=4c6b4ca60c6184c957aca9e6fc8e1335a56ea051fa450eb2
[I 02:55:10.045 LabApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 02:55:10.194 LabApp]

    To access the notebook, open this file in a browser:
        file:///C:/Users/Jaepil/AppData/Roaming/jupyter/runtime/nbserver-37000-open.html
    Or copy and paste one of these URLs:
        http://localhost:8888/?token=4c6b4ca60c6184c957aca9e6fc8e1335a56ea051fa450eb2
     or http://127.0.0.1:8888/?token=4c6b4ca60c6184c957aca9e6fc8e1335a56ea051fa450eb2

• What did you expect to occur after running these commands?

I expected it to terminate with ctrl+c but it never did. Actually, nothing did. IT'S IMMORTAL.

• What actually happened instead?

It just goes on. It does terminate normally on Powershell, cmd, Anaconda prompt, etc with ctrl+c

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

Not a specific repo. I suspect it happens with most of the process running in the bash since I can search many cases reporting the similar issue.
Since the prompt is gone whilte the process runs, I can't kill it with a command in the same terminal.

[PhilipOakley]

Does this need the winpty fix?

See release notes (~C:\Program Files\Git\ReleaseNotes.html)
Some console programs, most notably non-MSYS2 Python, PHP, Node and OpenSSL, interact correctly with MinTTY only when called through winpty (e.g. the Python console needs to be started as winpty python instead of just python).

Just a wild stab in the dark, but worth checking.

[jaepil-choi]

@PhilipOakley Tried it, but no luck. Can't even run the code properly.
$ winpty jupyter lab also doesn't work.

Of course, I have added poetry to my PATH. (Otherwise, it wouldn't have been called in the second prompt)

Jaepil@Jaepil-PC MINGW64 /e/VSCodeProjects/finance_essentials_37-64
$ winpty poetry run jupyter lab
winpty: error: cannot start 'poetry': Not found in PATH

Jaepil@Jaepil-PC MINGW64 /e/VSCodeProjects/finance_essentials_37-64
$ poetry
Poetry version 1.0.2

USAGE

[UnicodeEncodeError]
'cp949' codec can't encode character '\xa0' in position 30: illegal multibyte sequence

Funny thing is that it terminates as expected on VSCode bash terminal. VSCode terminal is supposed to be the same Git for Windows Bash, right? It's confusing.

[dscho]

Funny thing is that it terminates as expected on VSCode bash terminal. VSCode terminal is supposed to be the same Git for Windows Bash, right?

The Ctrl+C handling is not the responsibility of the Bash, but of the terminal in which you run it. And VS Code seems to make use of the relatively new PTYs while MinTTY (which operates the terminal window used by Git Bash by default) does not (yet).

[jaepil-choi]

@dscho Didn't know that. For the time being, I'm running things on VSCode Bash as much as possible to avoid this situation. However, I hope this gets resolved in later versions.
Should I keep this issue open? Using VSCode is definitely a workaround but it's still a bug.

[dscho]

I hope this gets resolved in later versions.

Well, this is Open Source, baby. If you don't care enough to fix this, you will need to very lucky for another volunteer to care enough.

On the other hand, I understand a lot about this issue, as it has come up before, and is essentially hard to solve.

Should I keep this issue open? Using VSCode is definitely a workaround but it's still a bug.

It is a bug. But if nobody works on it, we should close it. Let's give it a few weeks?

[jaepil-choi]

@dscho Thanks for the heads-up. I hope I could fix it but I'm not guru enough and the only language I know is Python - when non-Python languages take up about 98% of the code.
I'll keep it open just in case.
At least someone who stumbles upon the same issue can easily get a workaround by using VSCode for now.

[dscho]

I'll keep it open just in case.

Nah. It's only in the way, nobody will pick it up.