stack ghci in cygwin/msys bash chokes on Ctrl-C

[conklech]

Running ghci in a bash prompt on Windows with Cygwin/MinGW64 is a recepie for trouble; pressing control-C closes GHCI but then also kills the console window.

stack ghci exhibits the problematic behavior:

$ stack ghci
[..]
> <Ctrl-C>
$ [crash]

GHCI itself detects and warns of this problem and instructs the user to use ghcii.sh instead. This warning is for some reason suppressed with stack ghci.

ghcii.sh is a script in the GHC bin directory with these contents:

#!/bin/sh
exec "$(dirname "$0")"/ghc --interactive "$@"

That invocation somehow resolves the problem. stack exec ghcii.sh fails:

C:\Users\chris_000\AppData\Local\Programs\stack\i386-windows\ghc-7.10.1\bin\ghcii.sh:
  createProcess: invalid argument (Exec format error)

stack exec -- ghc --interactive also fails, under slightly different circumstances. Whereas stack ghci causes a shell crash immediately after the subsequent $ prompt appears, stack exec -- ghc --interactive causes a _hung_ shell; another Ctrl-C is required to prompt Windows to actually kill the console window.

None of this applies to the normal Windows command prompt. It can be worked around by quitting with :q rather than Ctrl-C.

I don't think this is a high-priority issue.

[chrisdone]

Hmm, then perhaps on Windows it should run this GHCi script?

[borsboom]

Based on this page sounds like ghcii probably shouldn't be used if running from the standard command-prompt (so only when in msys and cygwin). Is there a correct way to detect whether running under msys/cygwin and only use ghcii.sh in that case?

[conklech]

Running stack exec -- sh /path/to/ghcii.sh doesn't solve the control-C problem, unfortunately. It's actually worse: Ctrl-C appears to kill ghc, but it doesn't; the shell gets in a hung state, as I described above, _and_ ghc.exe lingers, pegged to 100% of its CPU thread for whatever reason, until killed through Task Manager.

Likewise making a stack.sh wrapper around stack itself: no dice.

I don't know why the ghcii.sh wrapper works, anyway. (It still does, by the way, just not when called through stack.)

The MSYS2 MinGW shell can be detected by the presence of the environment variable $TERM, which isn't set (by default) in a normal Windows console, but is set to xterm-256color (on my system) in the msys2 shells. I don't know if that's how GHC knows to display its internal warning.

The MSYS2 shell runs through the console emulator mintty. As I've learned over the past few minutes, console emulation on Windows is not a solved problem. For the record, here is the mintty issue on the subject. There are some proposed workarounds there; none looked very promising for our use-case. It looks like it was formerly possible to run Cygwin in a normal Windows shell (triggering various different problems), but I don't see any suggestion that that's still possible with MSYS2.

Unfortunately, I don't have much of a proposed way forward at the moment, other than perhaps issuing a warning not to hit control-C.

[conklech]

As a workaround, installing the winpty package (pacman -S winpty) and using it, $ winpty stack ghci, seems to resolve the problem just fine, and also makes the arrow keys and tab completion work properly.

This should be documented, but that's outside the scope of the stack project. I'm thinking of making a centralized document regarding using MSYS2 to build and distribute Haskell packages. But it'll have to wait--I'm taking the bar exam next week (finally!) so I'll be out of action until August.

(Recall that all of this only applies when using MSYS2, cygwin, or another POSIX-style console on Windows.)

The remaining bug regarding stack is that stack ghci suppresses the warning message that regular ghci provides, without providing an alternate warning and suggested workaround. As discussed in previous comments, (1) we're not sure why that happens, and (2) the ghcii.sh workaround provided with GHC doesn't work under stack.

[tomberek]

I can confirm this while using Babun.

[Blaisorblade]

FWIW, I think stack exec ghcii.sh works better now inside the "Git Bash" shell from "Git for Windows", which uses mintty — at least on Windows 10. To get the effect of stack ghci (which is different from stack exec ghci), one would have to also try stack ghci --with-ghc ....