Ctrl-C kills cabal repl on windows

[ambroslins]

Describe the bug
Using Ctrl + C inside cabal repl (to clear the line or interrupt a long running command) closes the repl on windows.

To Reproduce

$ cabal v2-repl

• Press Ctrl + C

Expected behavior
I expect the repl to stay open after using Ctrl + C, as ghci and cabal repl on WSL stay open after the interrupt.

System information

• Operating system: Windows 10
• cabal version 3.6.2.0 (installed with ghcup)

Additional context
I think this is the same as #1448, but I opened as new issue as this is windows specific.

I also tested the commit 9e417fa built with ghc 8.10.7 and 9.2.5, but it has the same problem.

[ulysses4ever]

Thanks for the report and a lot of datapoints!

Thoughts. Looks relevant: #8208, where they say that the bug may have been introduced in #7921

Suggestions:

• Since you have ghcup handy, could you try:
  • cabal 3.8.1.0
  • cabal 3.9.0.0 pre-release (for that you'll need the prerelease channel)
  • a newer, "internal" prerelease via:

  ghcup --no-cache install cabal -u 'https://gitlab.haskell.org/haskell/cabal/-/jobs/1387822/artifacts/raw/out/cabal-install-3.10.1.0-x86_64-linux-alpine.tar.xz' internal-third-prerelease-of-3.10
  

• Could you try to build cabal just prior Handle SIGTERM properly, on unix systems #7921 and right after it and check that this is the culprit?

[robx]

As far as I understand, #7921 didn't make it into cabal 3.6 (or even cabal 3.8), so it's unlikely to be the cause here. It should be in that 3.9 pre-release though, and might even help here judging by the PR description, since I claim it improves Ctrl-C behaviour on Windows 😅.

I think #7929 is the only one of my somewhat related changes that is in Cabal 3.8, but that shouldn't interfere.

It would be interesting to know if/when this ever worked on Windows -- the thing that's involved on the Unix side is System.Process's delegate_ctlc setting, which is documented to have no effect on Windows. One thing that might be worth playing around with is enable_process_jobs.

[ambroslins]

Sure, here are my results.

cabal 3.8.1.0 and pre-release cabal 3.9.0.0:

Same problem, but if I run cabal repl in my home directory (no cabal project) it does exit with:

λ> C:\Users\Ambros\AppData\Local\Temp\cabal-repl.-20236: removeDirectoryRecursive:removeContentsRecursive:RemoveDirectory "\\\\?\\C:\\Users\\Ambros\\AppData\\Local\\Temp\\cabal-repl.-20236": permission denied (The process cannot access the file because it is being used by another process.)

Inside a project it does exit the repl but without printing anything.

The provided command for the "internal" prerelease does not work for me, I also tried to replace linux-alpine.tar.xz with windows.zip but that does not exists.

cabal 3.7.0.0 55e036a

Same as 3.8.1.0 and 3.9.0.0

cabal 3.7.0.0 0184445

Same as 3.8.1.0 and 3.9.0.0

[ambroslins]

@robx

It would be interesting to know if/when this ever worked on Windows -- the thing that's involved on the Unix side is System.Process's delegate_ctlc setting, which is documented to have no effect on Windows. One thing that might be worth playing around with is enable_process_jobs.

I just tested the following cabal version with ghcup and all of them exit the repl:

• 2.4.1.0
• 3.0.0.0
• 3.2.0.0
• 3.4.1.0
• 3.6.0.0

[robx]

Awesome, thank you! Not a regression then, "just" one of the bugs around Windows subprocess handling.

Here's one instance where this was fixed for ghci itself: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8692. It appears that the parent process should be calling FreeConsole(). As far as I can tell, there are no Haskell bindings to that function (neither in the package Win32 nor is it used within process).

I was going to suggest extending process to add a call to FreeConsole(), but ran across the flags detach_console and create_new_console -- I hope these might have a similar effect. If you/anyone wants to try this, it could be set here:

cabal/Cabal/src/Distribution/Compat/Process.hs

Line 61 in ab24689

proc path args = enableProcessJobs (Process.proc path args) { Process.delegate_ctlc = True }

(or possibly at a narrower scope higher up in the callstack if setting it for all subprocesses causes issues).

[jneira]

hmm thanks for the report, i just tried to reproduce and it worked for me;

PS D:\dev\ws\haskell\cabal-test> cabal repl
Build profile: -w ghc-8.10.7 -O1
In order, the following will be built (use -v for more details):
 - cabal-test-0.1.0.0 (lib) (first run)
Preprocessing library for cabal-test-0.1.0.0..

GHCi, version 8.10.7: https://www.haskell.org/ghc/  :? for help
......

*Lib> Control.Monad.forever (putStrLn "x")
x
....
x
xInterrupted.
*Lib> putStrLn "Still in the repl"
Still in the repl

I tried cabal-3.9.0.0, not sure which commit but a recent one and cabal-3.8.1.0, using powershell on windows 10

[ambroslins]

@jneira

hmm thanks for the report, i just tried to reproduce and it worked for me;
Hmm okey, I also tested this on my laptop with Windows 11 and there the repl also closes on the interrupt.
I also checked Windows PowerShell, PowerShell Core and cmd and all behave the same.
This is my output:

Ambros@Ambros-PC in ~\Dev\cabal-interrupt-test
> cabal repl
Build profile: -w ghc-9.2.5 -O1
In order, the following will be built (use -v for more details):
 - cabal-interrupt-test-0.1.0.0 (lib) (ephemeral targets)
Preprocessing library for cabal-interrupt-test-0.1.0.0..
GHCi, version 9.2.5: https://www.haskell.org/ghc/  :? for help
Ok, one module loaded.
ghci> getLine
*** ExceptioInterrupted.
ghci>
Ambros@Ambros-PC in ~\Dev\cabal-interrupt-test
>

@robx

I was going to suggest extending process to add a call to FreeConsole(), but ran across the flags detach_console and create_new_console -- I hope these might have a similar effect. If you/anyone wants to try this, it could be set here:

cabal/Cabal/src/Distribution/Compat/Process.hs

Line 61 in ab24689

proc path args = enableProcessJobs (Process.proc path args) { Process.delegate_ctlc = True }

I tried this and using create_new_console = True the repl does behave as expected, so stays open after the interrupt, but this opens a new terminal window so I don't think this is desired. With detach_console I get the following error:

> C:\Users\Ambros\AppData\Local\ghcup\cabal\bin\cabal.exe repl
Warning: cannot determine version of
C:\Users\Ambros\AppData\Local\ghcup\ghcup\bin\ghc.exe :
""
Error: cabal.exe: The program 'ghc' version >=7.0.1 is required but the
version of C:\Users\Ambros\AppData\Local\ghcup\ghcup\bin\ghc.exe could not be
determined.

Ambros@Ambros-PC in ~\Dev\cabal-interrupt-test
> C:\Users\Ambros\AppData\Local\ghcup\ghcup\bin\ghc.exe --version
The Glorious Glasgow Haskell Compilation System, version 9.2.5

[ulysses4ever]

@ambroslins sorry about the internal release link mixip: I should have known better than suggesting to get an alpine binary on Windows. Could you try this url instead:

https://gitlab.haskell.org/haskell/cabal/-/jobs/1387827/artifacts/raw/out/cabal-install-3.10.1.0-x86_64-windows.zip

[robx]

It might be worth trying across different ghc(i) versions, too. The following seems to work for that (with ghcup-installed ghc versions):

$ cabal repl -w ghc-8.10

I'm also curious whether there's a difference between cabal repl and cabal exec ghci.

[ambroslins]

@ambroslins sorry about the internal release link mixip: I should have known better than suggesting to get an alpine binary on Windows. Could you try this url instead:

https://gitlab.haskell.org/haskell/cabal/-/jobs/1387827/artifacts/raw/out/cabal-install-3.10.1.0-x86_64-windows.zip

Same issue.

It might be worth trying across different ghc(i) versions, too. The following seems to work for that (with ghcup-installed ghc versions):

$ cabal repl -w ghc-8.10

I'm also curious whether there's a difference between cabal repl and cabal exec ghci.

I tested with ghc 8.8.4, 8.10.7, 9.0.2, 9.2.5, 9.4.4 and all of them have this issue.
cabal exec ghci and ghci do not have this issue. They stay open after pressing ctrl + c. However I noticed that if I double press ctrl + c very fast it sometimes exits, not sure if this is intentional.

[Mistuke]

I think the difference is your terminals..

@jneira is trying using a native windows terminal, looks like Powershell.

@ambroslins is using what looks like an msys terminal? e.g. bash, sh, zsh etc. If this is the case then it's expected behaviour.

Cabal is a Windows program so it throws Windows signals, which are different from Unix signals and the emulated ones in msys processes. We cannot handle both at the same time.

you can use winpty cabal ... in an msys2 process to get native Windows behavior. (cabal is not the only program with this issue, e.g. running a native gdb in an msys2 terminal also behaves the same, that's why there are emulated posix ones too)

[jneira]

hmm it is somewhat hidden in the quote but

I also checked Windows PowerShell, PowerShell Core and cmd and all behave the same.