21

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?

ominug
  • 1,422
  • 2
  • 12
  • 28
  • I've also noticed this, so I'll be glad to see an answer, too. Perhaps it *is* a bug? – AJF Jun 16 '15 at 20:09
  • 8
    I fear that the latter command is never allocating memory. In such case, the GHC thread scheduler is (IIRC) unfair, and will never transfer control to other threads, or allow the async exception from Ctrl-C to be delivered. (To be honest, this used to be the case a long time ago, and I don't know if they worked around this somehow.) – chi Jun 16 '15 at 20:13
  • I know the problem you're talking about, but at least for me (in GHC-7.10), Ctrl+C _does_ interrupt `last (repeat 0)`! – Daniel Wagner Jun 16 '15 at 20:26

3 Answers3

15

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.

ivanjermakov
  • 1,131
  • 13
  • 24
14

(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 run jobs 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.

Daniel Wagner
  • 145,880
  • 9
  • 220
  • 380
4

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)

Abhisek
  • 4,610
  • 3
  • 17
  • 27
  • 2
    Ctrl+D will not close ghci while it is executing code. Ctrl+Z, on the other hand, sends a signal that can't be caught or handled by the receiving process, so will always work (for any process, not just ghci). You can clean up after the leftover process left behind by Ctrl+Z with `kill` or similar, as discussed in my answer. – Daniel Wagner Mar 08 '18 at 15:19
  • Yeah.. `Ctrl+D` did not close my `ghci` when I ask it to compute `333^333^333` for me. – Student Sep 03 '19 at 19:11