(Caveat lector:.. Io uso Linux, e zsh corsa su urxvt o gnome-terminal Se si utilizza un sistema diverso operativo, terminale o shell, è possibile questo lavoro in modo diverso per voi)
Il Il modo in cui solitamente gestisco questo è di premere Ctrl + Z (che lo mette in secondo piano, sospendendo l'esecuzione interamente come un effetto collaterale) e poi uccidi il lavoro. Di solito questo è kill %1
, anche se è possibile eseguire jobs
per ricontrollare.
È anche possibile avviare un nuovo terminale e fare qualcosa come killall -9 ghci
, ma questo ha un costo di risorse molto più alto: si stanno generando alcuni nuovi processi, si aprono connessioni X, si fa tutto ciò che fa il terminale quando si inizializza, fare tutto ciò che fa la shell quando si inizializza da solo, ecc. Se ti trovi nella situazione, mi trovo spesso in - ghci si sta scambiando come un matto - che dà a ghci più tempo per rovinare tutto.
fonte
2015-06-16 20:25:28
Ho anche notato questo, così sarò felice di vedere una risposta, anche. Forse * è * un bug? – AJFarmar
Temo che quest'ultimo comando non stia mai assegnando memoria. In tal caso, lo scheduler dei thread di GHC è (IIRC) sleale e non trasferirà mai il controllo ad altri thread, né permetterà che l'eccezione asincrona da Ctrl-C venga consegnata. (Per essere onesti, questo era il caso molto tempo fa, e non so se hanno lavorato attorno a questo in qualche modo.) – chi
Conosco il problema di cui stai parlando, ma almeno per me (in GHC- 7.10), Ctrl + C _does_ interrupt 'last (repeat 0)'! –