When I launch
ghci> last [0..]
I can interrupt it with Ctrl+C.
However
ghci> last (repeat 0)
cannot be aborted with Ctrl+C. GHCI silently ignores the keystrokes.
How to abort this command in GHCI? Is it a bug?
You can quit GHCI using :quit
command
Prelude> :quit
Leaving GHCi.
Or by pressing Control+D that sends EOF signal.
If GHCI is busy you have no choice other than killing the process manually.
Ctrl+Z
seems to leave the shell, but it doesn't entirely close the process.
For Example
$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
Prelude>
[4]+ Stopped ghci
$ ps
PID TTY TIME CMD
3160 pts/1 00:00:00 bash
3554 pts/1 00:00:21 emacs
5602 pts/1 00:00:00 ghc
5693 pts/1 00:00:00 ps
However if you do Ctrl+D
$ ghci
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
Prelude>
Leaving GHCi.
$ ps
PID TTY TIME CMD
3160 pts/1 00:00:00 bash
3554 pts/1 00:00:21 emacs
5870 pts/1 00:00:00 ps
So the proper way to close haskell-shell
is to hit Ctrl+D
.
Note: Tested on Linux (Ubuntu 16.04 LTS)
(Caveat lector: I use Linux, and run zsh on urxvt or gnome-terminal. If you use a different operating system, terminal, or shell, it's possible this will work differently for you.)
The way I usually handle this is to hit Ctrl+Z (which puts it in the background, pausing execution entirely as a side-effect) then kill the job. Usually this is
kill %1
, though you can runjobs
to double-check.You can also start a new terminal and do something like
killall -9 ghci
, but this has a much higher resource cost: you are spawning a few new processes, opening X connections, doing whatever it is your terminal does when it initializes itself, doing whatever it is your shell does when it initializes itself, etc. If you're in the situation I often find myself in -- ghci is swapping like crazy -- that just gives ghci more time to screw things up.If you can predict this problem, and are compiling, you can use
-fno-omit-yields
to ask GHC to insert Ctrl+C checks even inside tight, non-allocating loops.