I just lost a lot of computation when a long-running program of mine was unceremoniously destroyed by xmonad. Now, I take almost full responsibility for this mishap, because I *did* in fact instruct xmonad to obliterate my entire X11 session by issuing the keys `mod-shift-q'. However, that instruction was a mistake; I didn't at all have that action in mind when my fingers went for it---and I'm a longtime user who almost never presses that! A goal of xmonad is to make the user more efficient, but I think this kind of efficiency is not what is intended! I'm no fan of forcibly hand-holding people, but I think it would be wise at least to show people up front how to configure xmonad to confirm this request (especially if it can be determined that information would be destroyed). Even better, a vanilla xmonad should probably come already configured with such a basic safety mechanism (a power user who doesn't want to be pestered with such trivial second-guessing could disable it). Sincerely, Michael Witten
On Mon, Dec 26, 2011 at 07:44:40AM -0000, Michael Witten wrote:
I just lost a lot of computation when a long-running program of mine was unceremoniously destroyed by xmonad.
XMonad aside, I always run long-running computations inside GNU screen, to avoid any risk of accidentally killing them by logging out, or killing the terminal, or other such pitfalls (the probability of which mysteriously seems to increase exponentially the longer and more important the computation is!) If your computations are command-line programs (most are), you might find it useful. Best, Toby -- Dr T. S. Cubitt Mathematics and Quantum Information group Department of Mathematics Complutense University Madrid, Spain email: tsc25@cantab.net web: www.dr-qubit.org
On Mon, Dec 26, 2011 at 12:47, Toby Cubitt
On Mon, Dec 26, 2011 at 07:44:40AM -0000, Michael Witten wrote:
I just lost a lot of computation when a long-running program of mine was unceremoniously destroyed by xmonad.
XMonad aside, I always run long-running computations inside GNU screen, to avoid any risk of accidentally killing them by logging out, or killing the terminal, or other such pitfalls (the probability of which mysteriously seems to increase exponentially the longer and more important the computation is!)
If your computations are command-line programs (most are), you might find it useful.
Indeed! My computation was indeed being performed by a command-line program, and as soon as I had committed my lamentable mistake, GNU screen was the very first thing that crossed my mind. Fortunately, I *was* using GNU screen for something even more important: IRC chatting :-)
On Mon, 26 Dec 2011 07:44:40 -0000,Michael Witten
I just lost a lot of computation when a long-running program of mine was unceremoniously destroyed by xmonad.
Now, I take almost full responsibility for this mishap, because I *did* in fact instruct xmonad to obliterate my entire X11 session by issuing the keys `mod-shift-q'. However, that instruction was a mistake; I didn't at all have that action in mind when my fingers went for it---and I'm a longtime user who almost never presses that!
A goal of xmonad is to make the user more efficient, but I think this kind of efficiency is not what is intended!
I'm no fan of forcibly hand-holding people, but I think it would be wise at least to show people up front how to configure xmonad to confirm this request (especially if it can be determined that information would be destroyed). Even better, a vanilla xmonad should probably come already configured with such a basic safety mechanism (a power user who doesn't want to be pestered with such trivial second-guessing could disable it).
I had a similar problem in November, and asked in the list for a workaround (confirmation of exit, or four-key combinations). This is the thread http://www.haskell.org/pipermail/xmonad/2011-November/011984.html I am happily using Daniel's solution, after changing the order of "yes\nno\n", to make the default be "no" since I very, very rarely exit xmonad (on purpose). Best, R.
Sincerely, Michael Witten
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad -- Ramon Diaz-Uriarte Department of Biochemistry, Lab B-25. Facultad de Medicina (UAM) Arzobispo Morcillo, 4 28029 Madrid Spain
Phone: +34-91-497-2412 Email: rdiaz02@gmail.com ramon.diaz@iib.uam.es http://ligarto.org/rdiaz
Hi, If you just don't want to quit by error your X11 session (with your running programs), you can do something like this. /home/user/.xinitrc while :; do xmonad if [ `echo -e 'no\nyes' | dmenu -p 'Do you really want to quit xmonad?'` = "yes" ]; then break fi done So, if you say yes, X11 quits, if not, xmonad will be relaunched with its programs, but it will not remember layouts and you maybe will need to readjust manually some order apps, but it works as a workaround to prevent kill x11. Hope it helps. On 12/26/2011 08:44 AM, Michael Witten wrote:
I just lost a lot of computation when a long-running program of mine was unceremoniously destroyed by xmonad.
Now, I take almost full responsibility for this mishap, because I *did* in fact instruct xmonad to obliterate my entire X11 session by issuing the keys `mod-shift-q'. However, that instruction was a mistake; I didn't at all have that action in mind when my fingers went for it---and I'm a longtime user who almost never presses that!
A goal of xmonad is to make the user more efficient, but I think this kind of efficiency is not what is intended!
I'm no fan of forcibly hand-holding people, but I think it would be wise at least to show people up front how to configure xmonad to confirm this request (especially if it can be determined that information would be destroyed). Even better, a vanilla xmonad should probably come already configured with such a basic safety mechanism (a power user who doesn't want to be pestered with such trivial second-guessing could disable it).
Sincerely, Michael Witten
_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
-- rga@sdf.lonestar.org
participants (4)
-
Michael Witten -
Ramon Diaz-Uriarte -
Ruben Gonzalez Arnau -
Toby Cubitt