Shortening the rope

By Jonathan Corbet
April 3, 2009

There are many things which could be said to be a part of the Unix philosophy. One of those, certainly, is that the operating system should stay out of the user's way to the greatest extent possible, even if said user is intent on doing something harmful. There is a classic quote attributed to Eric Allman:

Unix gives you just enough rope to hang yourself -- and then a couple of more feet, just to be sure.

Anybody who has administered Unix-like systems for long enough has probably ended up swinging from that rope at least once. So one would think that there might be support for work which reduces the potential for self-hanging. And indeed there is, but that doesn't mean that all such changes are welcome.

Readers with a lot of spare time and a desire to wander into email flamewars could probably occupy themselves with this fedora-devel thread for quite some time. It seems that the X.org developers recently decided that the three-finger salute (alt-control-backspace) should no longer, by default, immediately kill the X server. The reasoning behind this change is clear enough: it can be really irritating to hit the wrong key sequence and watch all of one's work evaporate before one's eyes. Besides, the environmental costs of replacing all of those thrown-across-the-room keyboards is increasingly hard to justify.

Unfortunately for the polar bear population, the change inspired a rather severe storm of flying keyboards in its own right. A certain Gerry Reno complained on fedora-devel that Fedora should have overridden X.org's decision regarding this key sequence. Unsatisfied with the hundreds of responses found there, he took the discussion to the X.org development list, wherein he claimed:

I read in the Fedora Release Notes the assertions that this change was due to users complaining about confusion regarding the control key sequences relating to the X server. That argument was no doubt made by some in the Emacs community who find that the Emacs key sequences are similar to the Xorg sequences... I am concerned because it appears that a tiny minority of Emac [sic] users have managed to lobby for a very significant change in default behavior for X server control to the detriment of the majority of users and administrators in the Linux community.

So, it seems, we have a conspiracy of Emacs users working to deprive the wider user community of a useful tool. Daniel Stone, the developer who committed this change, denies this charge:

I don't use Emacs myself, and I don't recall a single Emacs user complaining about accidentally triggering Ctrl-Alt-Backspace on their way to M-C-E-A-S paste-output-of-doctor-into-irc. Most of the grumbling came from actual users (i.e. people who don't know what an X server is, let alone how to configure it, let alone to email xorg-devel@ about it), rather than people who are perfectly capable of changing the default.

(It's worth noting that the Fedora Weekly Webcomic blames a different conspiracy for this change).

In truth, it's clear that a number of reasonably capable users have, at times, lost work as a result of hitting this key sequence by mistake. Enough of those users complained that the X.org developers looked at the issue, and, according to Matthew Garrett, "Everyone involved agreed that not having a keystroke that caused immediate data loss was a sensible idea." So, while many of the world's ills can legitimately be blamed on Emacs users, that would not appear to be the case this time around.

A reversal of this decision is unlikely. But the development community would still like to accommodate users who feel the need for the full length of rope. Said users can reverse the default in their xorg.conf file now, of course. The openSUSE approach has been to require that the sequence be hit twice before bringing the world to an end, but it's not clear that other distributors will follow suit. There has been discussion of moving the action to a key sequence which is harder to hit by accident. There may eventually be a per-user configuration option to enable this behavior as well, though that will require some X server changes first.

Meanwhile, Ubuntu developers have cut off a classic piece of Unix rope by boldly disabling the "rm -rf /" command. It seems that the rm command has a --preserve-root option which prevents the removal of the root directory. In Ubuntu, this option was not enabled by default, leading to the bug filed by a concerned user. The distribution's developers agreed that the ability to remove the root directory was not a particularly useful feature, and, additionally, that issuing an "rm -rf /" command was easier than one might expect - poorly-written scripts are evidently a common source of that kind of mistake. So, in October, 2008, they made --preserve-root the default for the Intrepid and Hardy releases.

Some months later, we have started to see complaints like this:

Life is full of dangerous choices. Using rm is one of them, or at least it should be. It's the price you pay to learn to be careful. It's the cost of being in control of your system.

and this:

Linux only makes one promise and that is your computer will do what you tell it to, not ask if you're sure, not safeguard you from your own ignorance.

Those who are concerned about this change have more to worry about: it would appear that Fedora has followed suit. Even so, the rope has not been shortened by any great length; those wishing to hang themselves can use any of a number of alternatives, including:

    rm -rf /.
    rm -rf ~
    rm -rf *

and so on. And, of course, the --no-preserve-root option remains available for those to can't think of any other way to destroy their systems.

But is this contrary to the Unix philosophy? If so, one should certainly complain about the much more obnoxious

    alias rm='rm -i'

.bashrc entries that Fedora has been inflicting on the root account for years. That is the sort of change that trains users to blindly agree to anything the system asks; your editor (who immediately removes such things) feels that overall user safety is not improved by asking "really do this?" questions all the time.

The truth of the matter, though, is that Linux has moved beyond the "hardy pioneers on the dangerous frontier" stage. Simple ability to hang one's self is of limited value even to pioneers; it is positively detrimental to those who come after. It is not surprising that developers and distributors are trying to disarm some of the most surprising and least useful booby traps in the system. That process is likely to continue. But this is still Linux, so those of us who feel the desire will always be able to break out the full length of rope; we'll just have to remove the warning label first.

(Log in to post comments)

Shortening the rope

Posted Apr 3, 2009 19:04 UTC (Fri) by joey (guest, #328) [Link]

Whatever happened to the idea that ctrl-alt-backspace could be used to ensure that one is really interacting with gdm/xdm, and not with a clever password logging imitation?

Shortening the rope

Posted Apr 3, 2009 19:21 UTC (Fri) by yokem_55 (subscriber, #10498) [Link]

Ctl-alt-printscreen-k handles this use case quite well. Comes in handy also when the X server goes completely out to lunch and isn't responding to keyboard inputs.

Shortening the rope

Posted Apr 4, 2009 12:28 UTC (Sat) by Trelane (subscriber, #56877) [Link]

except on my netbook, where Ctrl+Fn+Ins+k equates to Ctrl+PrtSc+2

Shortening the rope

Posted Apr 3, 2009 19:38 UTC (Fri) by SLi (subscriber, #53131) [Link]

Seriously, SAK is the one thing that is seriously lacking in Linux. The
Windows model of using Ctrl-Alt-delete for an uncatchable (by a non-root)
thing always before having to enter a password is really a good thing and
prevents malicious programs from capturing things. Although I hear the
implementation is not that good, but the idea is a correct one, and the
Linux world lacks even the idea. (There's a SAK in Magic SysRq and one can
be done with loadkeys, but they are not integrated at all with
X/KDE/Gnome/whatever and hence of limited use.)

Shortening the rope

Posted Apr 7, 2009 13:34 UTC (Tue) by hmh (subscriber, #3838) [Link]

Properly done SAK should done by the kernel, for it to have a chance of being somewhat secure. It doesn't have to, nor should it be "integrated" to anything: that goes completely against what SAK is supposed to do.

What one should do is to make sure the kernel will select the correct crap for killing, and that it resets the VT (and the keyboard translation mode, damn PeeCee legacy crap) to something that can work with getty for when X doesn't come back up. And to have init or another process supervisor bring gdm/kdm back to life.

For all I know, it even already does the above :-) I should try it one of these days.

Shortening the rope

Posted Apr 19, 2009 9:44 UTC (Sun) by TRS-80 (guest, #1804) [Link]

With GDM at least, the SAK kills the child gdm process on the terminal, but not the parent daemon, which then spawns a new child that starts X. I tested this yesterday, as I needed to restart X to get back the 1.5GB of RAM mozilla had leaked into it. Keyboard-wise X should be using the same translation as the VT thanks to input-hotplug, not that there's a getty on that VT.

Shortening the rope

Posted Apr 8, 2009 6:07 UTC (Wed) by daniels (subscriber, #16193) [Link]

Ctrl-Alt-Backspace is not an SAK and never has been, because a malicious program could simply remap the keyboard such that Ctrl-Alt-Backspace didn't terminate, then grab and play around with turning your display off and on to simulate a server restart.

Shortening the rope

Posted Apr 10, 2009 18:13 UTC (Fri) by madscientist (subscriber, #16861) [Link]

I think the point being made here is that there would be NO WAY to override this, including key remapping (well,there's nothing we can do about someone performing hardware hacks on your keyboard :-)). Or, probably preferably, you could override those keys individually but when pressed together they always trigger that particular event regardless of remapping.

Obviously, the choice of CTRL, ALT, and BACKSPACE for this purpose is sub-optimal for many reasons, not least of which is that they are often remapped.

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 19:27 UTC (Fri) by madscientist (subscriber, #16861) [Link]

All hail our Editor! Jon you are absolutely correct: before anyone should complain about these other minor and obscure issues, Red Hat should be appropriately flogged for this horrific default alias (Fedora just inherited this from Red Hat proper, AFAICT).

Anyone who sits down and thinks about it for a minute will realize that changing the behavior of a critical command like "rm" to increase the level of safety, using a method which is as transient and easily breakable as a shell alias, is a horrible idea. All you are doing is teaching people to assume and rely on the fact that "rm" will ask them before removing a file... so when they drop over to someone else's account, where this alias is not present, the potential for utter disaster is real and constant.

If Red Hat felt the need to create a "safer" rm, they should have used a different name such as "alias rmi='rm -i'" or similar.

Of course at this point they will argue that all their customers expect it so they can't change it. Sigh. This is how crap accretes.

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 20:18 UTC (Fri) by vblum (guest, #1151) [Link]

Odd ....

alias rm='rm -i'

has saved me a number of times, and there is always rm -f to undo it if need be ... so the _point_ is that -i is not a strong restriction, no?

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 21:07 UTC (Fri) by gmaxwell (guest, #30048) [Link]

But -f doesn't just undo it it also causes rm to remove readonly things that it would have previously stopped on

So by accepting this bit of 'protection' against one particular failure mode you've increased your exposure to another.

(The preserve root thing seems like 100% win to me)

Shortening the rope (around RH's neck)

Posted Apr 6, 2009 11:18 UTC (Mon) by vblum (guest, #1151) [Link]

hm, yes, but I tend to actually think twice before I ever type "-f" ... because that is not routine ... anyway, just a personal thing.

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 21:31 UTC (Fri) by mgh (guest, #5696) [Link]

heh - this will do what you want "\rm"

However, I have become so accustomed to using this form that I then to do it by default and have accidently removed files I didn't mean to ....

alias rm="rm -i" ends up being worthless because it drives the average user mad. But alias mv="mv -i" has saved me a few times and the same with cp.

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 21:35 UTC (Fri) by madscientist (subscriber, #16861) [Link]

If you weren't used to "rm" always asking, you'd be more careful (personally I use alias rm='rm -f' and I'm always careful :-)). Maybe you'd use "rm -i" explicitly when you wanted to be asked.

Believe me it doesn't take more than one time of not having that alias around, for whatever reason, running "rm" with the expectation it will ask you before deleting anything, and destroying important work to realize what a bad idea this is.

Shortening the rope (around RH's neck)

Posted Apr 5, 2009 19:09 UTC (Sun) by jengelh (subscriber, #33263) [Link]

If rm -f is considered too dangerous, and rm -i too noisy, then try something like

function rm()
{
mv "$@" "~/.trash";
}

and let cron evict it time and again.

Shortening the rope (around RH's neck)

Posted Apr 6, 2009 11:28 UTC (Mon) by vblum (guest, #1151) [Link]

hm, no, not true for me ... I was perfectly accustomed to to normal rm for a long time, until I once deleted my home directory. Once is all it takes (mind you, that was one out of >= 10^5 rm's that I ever typed).

Anything that asks you before deleting will make you think, even if it's after typing "y" for the 15th time ("hm .... strange that I am still typing "y" although I was only going to delete two files ... hm ...")

As for the second point, of course I wouldn't think of figuring out what I actually wanted to delete after being asked by -i ... that completely defeats the purpose of a safety net (and maybe that is why many in the thread do not understand why rm -i is a good thing, because it can be used for the purpose of making a deliberate selection ...)

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 22:07 UTC (Fri) by fmarier (subscriber, #19894) [Link]

Personally, I welcome some of the new protections. IMO It's not about losing control, it's about preventing smart and competent sysadmins from costly accidents.

For example, there are cases where I can see no good reason to be able to delete a specific directory (e.g. /, /bin, etc.). In fact, having done that by accident at some point, I would have preferred safer defaults.

That's why I decided to write safe-rm (http://www.safe-rm.org.nz) to blacklist certain directories and files. It's aliased to rm on my machine but I can always use "/bin/rm" if I really wanted to delete my /usr/lib.

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 23:51 UTC (Fri) by nix (subscriber, #2304) [Link]

What does safe-rm do that 'chattr +i' doesn't?

Shortening the rope (around RH's neck)

Posted Apr 4, 2009 7:17 UTC (Sat) by Cato (subscriber, #7643) [Link]

chattr +i would stop any changes at all to a file, including normal version upgrades of executables. Something like safe-rm is a bit more focused on preventing accidental deletions. However, "chattr +i / /usr" might be a good idea as it doesn't depend on someone using safe-rm etc.

Shortening the rope (around RH's neck)

Posted Apr 5, 2009 1:58 UTC (Sun) by Simetrical (guest, #53439) [Link]

chattr +i on a directory will stop any files in the directory from being modified, from a quick test, but it won't stop subdirectories from being removed recursively by rm -r. So it's only really useful on files, but you don't want to make files in /bin unmodifiable -- they need to be be changed in system upgrades. So for the same reason you don't want to make /bin unmodifiable (it seems to prevent some modifications to files it contains, certainly at least removal and likely overwriting of all kinds).

Shortening the rope (around RH's neck)

Posted Apr 5, 2009 11:56 UTC (Sun) by nix (subscriber, #2304) [Link]

Ew. I didn't realise that. That seems like an rm -r bug to me.

Shortening the rope (around RH's neck)

Posted Apr 5, 2009 17:11 UTC (Sun) by JoeF (guest, #4486) [Link]

Why not mount /, /bin,... read-only?
Keep everything you need to write to, e.g., /tmp, /var, on separate filesystems.
That's what I do, and it works nicely.
Of course, you could still end up deleting your home directory...

Shortening the rope (around RH's neck)

Posted Apr 7, 2009 13:44 UTC (Tue) by hmh (subscriber, #3838) [Link]

You need /etc to be RW, and you need that very early in the boot sequence, so it traditionally has to be inside /. That's the only thing that gets in the way of mounting / RO.

accidental deletion and read-only root filesystem

Posted Apr 9, 2009 23:37 UTC (Thu) by giraffedata (guest, #1954) [Link]

You do have to use a rather different filesystem layout than what comes with conventional Linux to have a read-only root filesystem. I've been doing it for years, though. Sometimes it's as easy as having symbolic links from the root filesystem to a read/write filesystem, but other times it's as hard as having to modify a program to eliminate a hardcoded file name.

I also do daily automated backups. Deleting my home directory wouldn't be particularly severe for me.

Shortening the rope (around RH's neck)

Posted Apr 17, 2009 11:34 UTC (Fri) by Ross (guest, #4065) [Link]

But rm isn't the only tool which can be misused. Do you have safe versions of tar, chmod, chown,
and mv for example? What about graphical file managers?

This seems much more like something you should be able to do through permissions rather than
adding special logic to every application to "know" what files should not be changed. And of course
there _are_ times you do want to change them even if it is rare, so the tools must also have an
override.

Shortening the rope (around RH's neck)

Posted Apr 4, 2009 15:21 UTC (Sat) by man_ls (guest, #15091) [Link]

I agree with you completely; enabling all the "-i" aliases is one of the first things I do for every new Debian user. Even for root. It seems that the rough Linux pioneers who shaved with rusty knives and for whom "Linux from scratch" was unnecessarily bloated have a different taste for danger than us settlers.

Shortening the rope (around RH's neck)

Posted Apr 3, 2009 22:53 UTC (Fri) by smoogen (subscriber, #97) [Link]

I believe the change was put in because of customer complaints back in the late 90's. And yes putting it in caused a calvacade of responses that Red Hat was the AOL of Linux.. or was that the Microsoft of Linux.. ranters couldn't decide which was worse and the flame war ended up with them tearing up each other over it.

In the end it was pointed out that is an alias which pretty much everyone of the ranters really didn't run into because well they had already made their own .bashrc as good hackers should. Those who had not.. well it was a good exercise on becoming a hacker in finding out how to ignore it.

Shortening the rope (around RH's neck)

Posted Apr 10, 2009 18:47 UTC (Fri) by madscientist (subscriber, #16861) [Link]

A lot of people are misunderstanding my comment, and thinking that I mean you should just use the default and never change it, and learn to live with the blood on the floor. That's not what I'm saying. What I mean is that it's irresponsible (at best) for Red Hat to ship their standard shell configuration, especially for root, where they override the default behavior of a critical application like rm to be something "safer".

I've said above, but I'll repeat: what this does is encourage people who learn Linux/UNIX on Red Hat systems to assume that the default behavior of rm is to ask before deleting every file. I'm sure everyone here can see why this is bad!

Those people go to someone elses system, or log in as a different account, or even write a shell script!, or whatever that doesn't happen to have that magical alias installed, and they run rm expecting to be asked about every file... and before they know it they've deleted an entire directory or worse.

I have similar complaints about those of you who say you set up your user's accounts to contain this alias before they ever log in. You may think you're doing them a service, but in the long run it's more dangerous.

I have no problem with creating a DIFFERENT alias, like "rmi", that aliases to "rm -i", and encouraging people to use that instead of "rm". And of course I have no problem with someone creating their OWN alias, in their own shell config file, to do whatever they want: hopefully they will be aware enough to be careful at that point. But it's wrong and dangerous to set aliases like this in the shell config of unsuspecting users.

Shortening the rope (around RH's neck)

Posted Apr 24, 2009 18:40 UTC (Fri) by Max.Hyre (subscriber, #1054) [Link]

All you are doing is teaching people to assume and rely on the fact that "rm" will ask them before removing a file... so when they drop over to someone else's account, where this alias is not present, the potential for utter disaster is real and constant.

Would that that were the only danger. The assumption and reliance mean that when they ``rm -r *'' and are asked for confirmation, they'll type in `y' without thinking—it becomes no protection at all.

True story:

Ages ago (25 years?) I worked on Datapoint systems, early versions of microcomputers. At the time, the only non-volatile storage was floppy disks, so we formatted and rewrote them continually.

Their format protection was of the form (sequence of answers real, questions forgotten, and so made up):

> format
- Are you sure? y
- Do you really want to wipe this disk? y
- Would you like to stop now, for safety? n
- This is your last chance, do you want to continue? y
<formats disk>

My fingers were so used to this rigmarole that typing ``yyny'' was controlled by my hindbrain—absolutely no thought involved. If I'd made a mistake, I had no more chance of catching it than if I'd typed ``# rm -rf /''.

Such mechanisms are a snare and a delusion.

FWIW: When I'm setting up some potentially disastrous command, I always start the line with `#'. That way, if my finger accidentally hits the <CR> key, Bash will just say ``Ho, hum—another comment.'' When I've built up the command to my satisfaction, I remove the hash and send the command on its way.

Shortening the rope

Posted Apr 3, 2009 19:28 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

I fear that this will reveal what an old geezer I am, but I've been using some flavor of Emacs (Gosling's Emacs or GNU Emacs) for 26 years now (OK, I started while in my teens, and at least I'm younger than RMS, but not by a whole lot).

I've never hit control-alt-anything by accident, or even on purpose as an Emacs key sequence, and that's because in Emacs, any alt-key can also be typed by preceding the key with ESC, so I would never attempt to hold down both control and alt and hit a key while using Emacs. That's reserved for special three-finger salutes, and it's painful enough to do that it's not going to happen unless I really, really intend to do that.

control-meta-H is "mark-defun" (mark the current function) in Emacs, but everyone types it as ESC followed by control-H. Anyone who ever does otherwise would long ago learned not to do that, since they would no longer have an X server.

Shortening the rope

Posted Apr 3, 2009 19:47 UTC (Fri) by Thue (guest, #14277) [Link]

Slightly related:

When running emacs in putty on Windows, I have accidentally hit CTRL-SHIFT. In user-friendly Windows, this enabled-by-default shortcut has the effect of changing my keyboard layout in the active application from Danish to US.

Having your keyboard layout changed is not very intuitive, especially since you will probably first notice the change many keystrokes later. It took me literally years of spurious keymap switches to figure out what was causing the problem.

Enlightenment...

Posted Apr 3, 2009 22:37 UTC (Fri) by alex (subscriber, #1355) [Link]

Ah that explains why I was getting confused when I was using a Windows box a few months back. I kept having to go into the localisation config panel to fix things.

Shortening the rope

Posted Apr 4, 2009 1:15 UTC (Sat) by dvdeug (subscriber, #10998) [Link]

Having your keyboard changed on you silently is no fun; I had my keyboard changed from US to German or something on an upgrade once, and spent the next few hours discovering why it wouldn't let me log in. My username, unlike my password, had all the characters on the same keys...

Shortening the rope

Posted Apr 3, 2009 22:37 UTC (Fri) by dododge (guest, #2870) [Link]

Yeah, I have to concur. I'm a 20-year user of emacs, and you could remove the alt keys from my keyboard and I'd hardly notice. I normally use the aforementioned ESC prefix instead, but if you don't want to move off the home row you can even get around that by using C-[. I think the last time I touched an actual meta key was on a DECStation keyboard in the early 90s, and it would never occur to me to try to chord those sequences on a modern system.

Also, I do use ctrl-alt-backspace on purpose all the time. At work I manually start the X server and use C-A-BS to quit on a daily basis. At home there is some sort of race such that the X server never sees all of my video cards immediately after a power cycle, until I C-A-BS gdm and let it probe a second time. Then there are crazy X11 bugs requiring a server restart, which I encounter up to several times a day on my home system (a problem that began immediately after I upgraded from Ubuntu 8.04 to 8.10, sigh).

Shortening the rope

Posted Apr 4, 2009 0:00 UTC (Sat) by nix (subscriber, #2304) [Link]

I'm a long-term XEmacs user who uses the meta key constantly, despite
starting out in TTYs with ESC the only option: but my keyboard (a Maltron)
is sufficiently bizarre that I had to almost relearn typing, at least
non-alphanumeric typing, when I switched. Learning to use the meta key was
easy when I was learning to use ctrl (next to it) and backspace (next to
that) at the same time.

(Yes, with ctrl-alt-backspace all in a line under my thumb I've been
running with DontZap for a *long* time.)

Shortening the rope

Posted Apr 8, 2009 21:48 UTC (Wed) by roelofs (guest, #2599) [Link]

(Yes, with ctrl-alt-backspace all in a line under my thumb...

I smell a Stones parody in there somewhere...

Shortening the rope

Posted Apr 9, 2009 4:39 UTC (Thu) by pr1268 (subscriber, #24648) [Link]

I smell a Stones parody in there somewhere...

Well, I have little Sympathy for the Devil who insists on shortening the rope too much. Don't they realize that You Can't Always Get What You Want? It's bad enough that I Can't Get No Satisfaction with all these extra X server options, and no one else wants to come to my Emotional Rescue when my X session is Shattered. My computer is a Beast of Burden; I cannot just Let It Bleed.

All I ask is that the developers Gimme Shelter from too short a rope. As for the bike shed (discussed by Thue below), why not just Paint It, Black?

Shortening the rope

Posted Apr 17, 2009 8:05 UTC (Fri) by nix (subscriber, #2304) [Link]

Not an intentional one, but it's nice watching people run with it :)

Meta Key

Posted Apr 6, 2009 2:38 UTC (Mon) by rfunk (subscriber, #4054) [Link]

"I think the last time I touched an actual meta key was on a DECStation
keyboard in the early 90s"

What, no Windows keyboard for you?

I map the Windows-logo key to Meta, since it sure looks to me like the
meta keys I had I my old Sun SparcStations. Similarly, Apple keyboards
have an Apple-logo key that serves the same purpose. Note that both Emacs
and X11 have a separate modifier code for Alt and Meta.

Meta Key

Posted Apr 9, 2009 5:44 UTC (Thu) by daniels (subscriber, #16193) [Link]

Strictly speaking, X has no 'modifier code' for Alt (though it can be mapped as a separate modifier via vmods), which is why Meta is generally used.

Meta Key

Posted Apr 17, 2009 12:31 UTC (Fri) by Ross (guest, #4065) [Link]

There are eight modifier flags, three of which have permanent meaning (shift, control, and
capslock). So really those are the only ones which are guaranteed to exist on every X server.

Meta, Alt, Hyper, Super, etc. can be mapped to any of the other five if those keysyms (or left or
right vaiants) exist.

My experience is that this stuff isn't very well documented and certain applications interpret things
a little differently.

Utility of ctrl-alt-backspace

Posted Apr 17, 2009 11:51 UTC (Fri) by Ross (guest, #4065) [Link]

I'm also a big use of the X server kill keystroke. I use it as a really fast logout mechanism all the
time. Of course I could change to another key sequence (though it wouldn't work when the
screen is locked), and I guess I will have to.

The bigger problem in X server and application bugs. There's no easy way to work around them
and the kill sequence is a quick way to recover. Yes, you can say these should be fixed,
but I've seen them for as long as I've used Linux which is more than a decade now. Whether
Firefox, OpenOffice, some full-screen game (the worst because they seem to make virtual
console switching fail when they lock up), or whatever locks up your session, this gives you a way
out.

Really, I'd like to see the X protocol extended so grabs weren't needed as often, and so there was
a safer way to do grabs. But that hasn't happened and it would take a long time for things to be
rewritten to take advantage of it.

The X server going into a catatonic state (or crashing, but at least then you can login and restart
it) is also something which is hard to fix, because there are so many different video cards and
extensions.

So, in summary, I hate to see this go without a replacement. Someone mentioned that Sun
requires you to hit the key sequence three times in a row -- that would be fine with me. The
alternative is to ssh in and kill things from another computer, or to power-cycle the box, which
isn't convenient.

Utility of ctrl-alt-backspace

Posted Apr 17, 2009 21:39 UTC (Fri) by oak (guest, #2786) [Link]

In the case of a keyboard grab, you can just switch to a virtual terminal
and kill the offending program (all toolkits popups use grabs so program
freezing with menu open e.g. to network timeout is pretty bad). That
releases the client's pointer/keyboard/server grab.

This helps only to grabs though, if X itself freezes, you cannot do the VT
switch as similarly to other FB apps, X would need to ACK the VT-switch
(at least until kernel can do the mode switches & palette save/restore on
VT switches by itself). Then you need to use the kernel SysRq key to kill
the whole X.

Shortening the rope

Posted Apr 4, 2009 6:26 UTC (Sat) by SimonKagstrom (guest, #49801) [Link]

I've also used Emacs for a long time, but I've managed to Zap X a number of times from within it. It's not really emacs fault since I've numerous times done the same from shells etc - Meta-backspace very conveniently deletes a word backwards.

Unfortunately, Ctrl and Alt are neighbors and placing fat fingers carelessly sometimes means *Zap* and all work lost. Adding DontZap is always one of the first things I do on a new desktop. First I open a lot of windows and perform a lot of work there, then Zap the desktop by mistake, and then remember to add DontZap.

Personally, I don't care what the default is - I know how to change it and have never seen as that much of a problem (most things get better if you have to redo them once!).

Shortening the rope

Posted Apr 3, 2009 20:07 UTC (Fri) by lmb (subscriber, #39048) [Link]

Seriously, do we have no larger problems? These minor issues - configurable, no less - just attract discussion participants who have nothing major to contribute.

I will admit to having been hit by the ctrl-alt-backspace accident, and losing data on a new laptop keyboard. So I welcome the change that this can be configured.

However, my gripe was not with X exiting immediately. But with the fact that applications like OpenOffice et al have no useful recovery code for such crashes. vi/emacs haven't lost me data, but suboptimal GUI applications incapable of a recoverable emergency exit have; probably brought to us by the same people who do not understand fsync().

Hence, my of course major contribution to this matter is that the bike shed should be painted black.

Shortening the rope

Posted Apr 3, 2009 20:49 UTC (Fri) by Thue (guest, #14277) [Link]

The color of that bike shed is very important...

Shortening the rope

Posted Apr 4, 2009 2:28 UTC (Sat) by ktanzer (guest, #6073) [Link]

I too hate apps that can't recover from a crash, but these days OO doesn't seem to be one of them. Their auto-recovery seems to be quite effective--you can lose a couple of minutes worth of work, but not a whole lot more. I guess it would be even better if it could save every last bit on crash, but no complaints here. I get more annoyed that OO doesn't know how to clear things out of its recovery queue, and will try to recover files long after they are gone.

Gimp, OTOH, could seriously use some crash recovery ability!

Removing policy from the X server

Posted Apr 3, 2009 20:35 UTC (Fri) by ebiederm (guest, #35028) [Link]

Sounds like X.org changed the default to give the user more rope to hang themselves with.

I'm going to miss SAK, but I'm not going to miss keystrokes I can't capture.

Removing policy from the X server

Posted Apr 4, 2009 3:30 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

ctrl+alt+backspace wasn't a SAK. It's part of the XKB mappings, so any application with authorisation to speak to the X server could unmap it and grab it.

Shortening the rope

Posted Apr 3, 2009 20:59 UTC (Fri) by clugstj (subscriber, #4020) [Link]

Jon, you didn't mention the discussion thread here about disallowing certain characters in file names.

Shortening the rope

Posted Apr 3, 2009 21:01 UTC (Fri) by evgeny (subscriber, #774) [Link]

> In truth, it's clear that a number of reasonably capable users have, at times, lost work as a result of hitting this key sequence by mistake.

Heh, just yesterday did that trying to kill an unresponsive X server in a Qemu box ;-)

Shortening the rope

Posted Apr 4, 2009 12:11 UTC (Sat) by RobWilco (guest, #40828) [Link]

Yep, me too, and just yesterday too.

Indeed, it is the lobby of virtual machines user (especially win2003 guest) which brought this issue to the table, not the Emacs lobby users.

Another rope-shortener: Fixing filenames

Posted Apr 3, 2009 21:24 UTC (Fri) by dwheeler (guest, #1216) [Link]

Another example of a rope-shortener is the discussion about Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems, as discussed in last week's LWN.

Another rope-shortener: Fixing filenames

Posted Apr 3, 2009 21:45 UTC (Fri) by ballombe (subscriber, #9523) [Link]

Actually restrincting filename is in conflict with rope shortening:

A good way to avoid rm * to remove your home directory is to do
file=$(echo -e "$HOME/\01"); touch $file; chmod 000 $file
However forbidding control characters in filenames would break that.

(Restricting filename breaks a number of programs, for example flwm and other windows managers that use filenames as menu titles.)

Another rope-shortener: Fixing filenames

Posted Apr 4, 2009 10:10 UTC (Sat) by modernjazz (guest, #4185) [Link]

> Actually restrincting filename is in conflict with rope shortening

Only if there isn't another way to solve the same problem, like putting
safeguards against deleting a home directory.

Another rope-shortener: Fixing filenames

Posted Apr 17, 2009 12:12 UTC (Fri) by Ross (guest, #4065) [Link]

This is a horrible idea.

First, which characters are "safe" is going to depend on context. Lots of shell scripts have trouble
with spaces in filenames. Some programs forget to escape strings used inside regular
expressions, so characters like "." and "?" would get in the way. And then there are characters
which can confuse people. Such as "S" vs. "5". Obviously we should only be using one or the
other. This is not even considering all of the variants of the same letter available in Unicode.
Let's also look at filename lengths; the only length that the majority of existing software can
handle properly is eight characters per file, 255 characters per path. Do we really want to limit
ourselves to "protect" against all these things?

Second, this is implementing policy which is in direct opposition to the previous policy: "no slash
or NUL". It would break all kinds of existing applications and scripts, break interoperability with
other systems, and generally make life more difficult.

Third, you can make conventions without enforcing policy. So don't write code which puts
hyphens and newlines in filenames. Just pick an encoding convention and stick with it (UTF-8 is
the obvious choice for Unix-type systems). Basically, take advantage of the fact that no policy is
being enforced by selecting your own.

I'm slightly surprised the proposal wasn't an April Fools joke :(

Shortening the rope

Posted Apr 3, 2009 22:22 UTC (Fri) by ikm (subscriber, #493) [Link]

I remembered all those stories where people buy a thing which claims itself to be unbreakable, waterproof, and so on, and so they immediately test that out by trying to break it or drown it, only to find out that the thing is then ruined, the manufacturer hasn't actually meant what they thought, and there's no warranty for such actions.

Aside from that, I also recalled a book Jon had referenced in some recent article, the "Unix-haters handbook". This very book had an extensive chapter on the article's topic, and I'd recommend checking it out for a fun read.

Emacs what?

Posted Apr 3, 2009 22:57 UTC (Fri) by smoogen (subscriber, #97) [Link]

Wow.. some people are so frothing about emacs and the secret conspiracy to replace the Linux kernel and X with it that they will come up with some amazing theories... To be honest I didn't know that the ALT key actually did anything in emacs til this article mentioned it.. I guess I should map it to the Windows Key so that I can actually use it for something.

rm -rf / limitation is from Solaris

Posted Apr 3, 2009 23:00 UTC (Fri) by tzafrir (subscriber, #11501) [Link]

Limiting 'rm -rf /' came from Solaris originally:

http://blogs.sun.com/jbeck/date/20041001#rm_rf_protection

And this is not only Ubuntu. E.g.: http://blog.venthur.de/2008/11/10/rm-rf/

rm -rf / limitation is from Solaris

Posted Apr 4, 2009 0:03 UTC (Sat) by nix (subscriber, #2304) [Link]

I wonder whether Solaris got it first or GNU coreutils?

* Major changes in release 5.1.0 (2003-12-21):

** New features
[...]
chgrp, chmod, chown, and rm accept the new options:
--preserve-root, --no-preserve-root (default)

rm -rf / limitation is from Solaris

Posted Apr 4, 2009 9:10 UTC (Sat) by tzafrir (subscriber, #11501) [Link]

Hmmm.... when you accidentally run 'rm -rf /' do you take the time to add --preserve-root to the command-line?

That extra switch is nice. However according to the coreutils changelog, --preserver-root was made the default of rm on 2006-02-09 (didn't check to which version it applies).

That 2004 blog entry is after the Solaris guys successfully changed POSIX, which I assume takes its own extra time.

Shortening the rope

Posted Apr 4, 2009 1:23 UTC (Sat) by russell (guest, #10458) [Link]

Please, won't somebody think of the children. We must eliminate these dangerous things. I propose we get rid of the power button next. It's the devils button.

Shortening the rope

Posted Apr 4, 2009 2:40 UTC (Sat) by pr1268 (subscriber, #24648) [Link]

Agreed. In fact, if we just got rid of the keyboard, then all these problems would disappear. Of course, productivity would also decrease substantially. ;)

Shortening the rope

Posted Apr 4, 2009 8:42 UTC (Sat) by russell (guest, #10458) [Link]

Maybe Fedora could consider putting this sort of stuff into a spin. They could call it Padded Cell Fedora. For people who have strange and uncontrollable urges to press random key sequences.

Shortening the rope

Posted Apr 4, 2009 18:47 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link]

To be clear, this is a upstream Xorg change and not a Fedora specific one.

Shortening the rope

Posted Apr 4, 2009 10:44 UTC (Sat) by bockman (guest, #3650) [Link]

Actually. I quite like the 'intelligent' power button of my iMac : short-time pressing mean suspend,
long-time pressing mean shutdown. For really hard shutdown, you can always unplug the thing :-)

Shortening the rope

Posted Apr 6, 2009 13:40 UTC (Mon) by clugstj (subscriber, #4020) [Link]

Wow, so the power button really doesn't have the capability to remove power?

Shortening the rope

Posted Apr 8, 2009 6:12 UTC (Wed) by daniels (subscriber, #16193) [Link]

Power buttons are universally understood to mean 'turn this thing off'. Backspace is ... not.

Even so, you'll note that pressing the power button these days just pops up a dialog box.

Shortening the rope

Posted Apr 8, 2009 7:28 UTC (Wed) by nix (subscriber, #2304) [Link]

Backspace turns off my Emacs all the time. ;)

Shortening the rope

Posted Apr 4, 2009 4:45 UTC (Sat) by MisterIO (guest, #36192) [Link]

The answer to this is very simple : put clear long options which you cannot choose by mistake(at least not a common mistake). For example it seems reasonable to force the use of --no-preserve-root if you really want to delete your root. The (alt-control-backspace) is a very good example of something that shouldn't be a default config IMO. In general this is somewhat an extension of the defensive programming concept.

Shortening the rope

Posted Apr 4, 2009 12:54 UTC (Sat) by ballombe (subscriber, #9523) [Link]

> The (alt-control-backspace) is a very good example of something that shouldn't be a default config IMO.

I disagree for a technical reason: the only time I use "alt-control-backspace" is just after installation to trouble-shoot the X server,
so it makes sense to have it activated in the initial configuration,
which is what default settings are for.

Furthermore, it would be smarter to keep DontZap to No but to map
Terminate_Server to no key. This way you can enable/disable alt-control-backspace without changing xorg.conf or even being root.

Shortening the rope

Posted Apr 4, 2009 19:45 UTC (Sat) by kov (guest, #7423) [Link]

I disagree for a technical reason: the only time I use "alt-control-backspace" is just after installation to trouble-shoot the X server, so it makes sense to have it activated in the initial configuration, which is what default settings are for.

You can always go to a terminal and kill it. Defaults are not 'initial settings supposed to be changed'. Defaults should be 'the setting that makes more sense, so that people won't have to change it'.

Shortening the rope

Posted Apr 5, 2009 19:40 UTC (Sun) by dambacher (subscriber, #1710) [Link]

I reconsidered the times I used CRTR-ALT-BACKSPACE: There were mostly two reasons to use it:

1) a program grabbed the keyboard and didn't let loose
2) a program grabbed the cpu and i was not able to open the terminal or switch console

In both cases I was happy to not holding down the power button for 3 seconds.

By the way: I never ever accidentally used ctrl-alt-backspace. I did run into an errorous rm -r in my base directiory though. But I learned from that...

Shortening the rope

Posted Apr 6, 2009 7:35 UTC (Mon) by nix (subscriber, #2304) [Link]

There is a grab-breaking key (which I forget) which you can use for the
first (also breaks server grabs, I think, not that those are used by
anyone, thank goodness).

Shortening the rope

Posted Apr 8, 2009 22:01 UTC (Wed) by roelofs (guest, #2599) [Link]

There is a grab-breaking key (which I forget)

    Option "AllowDeactivateGrabs"

...and then ctrl-alt-[keypad]divide. (The latter is one of only two computer commands I have on a PostIt on my monitor. :-) )

Greg

Shortening the rope

Posted Apr 17, 2009 19:29 UTC (Fri) by nix (subscriber, #2304) [Link]

Yeah, definitely gone in 1.6.x. Blast it.

Shortening the rope

Posted Apr 4, 2009 10:07 UTC (Sat) by stefanor (subscriber, #32895) [Link]

I'm one of the people who complained.

In particular, I find the default GNOME workspace-changing keypresses (Ctrl-Alt-Arrows) are too similar to Kill X. I think that default benign keypresses shouldn't be so similar to such dangerous ones.

Obviously people can reconfigure they GNOME/Emacs keypresses, but I consciously try to use the defaults (and get them changed where necessary), so that I don't get to out of touch with the defaults that I'm unable to use other people's computers.

Shortening the rope

Posted Apr 7, 2009 18:28 UTC (Tue) by hmh (subscriber, #3838) [Link]

Come on, how is Ctrl-Alt-BkSPC different from Ctrl-Alt-DEL? In fact, Ctrl-Alt-DEL is much closer to the arrow keys on most keyboards. If you're going to complain against Ctrl-Alt-BkSPC zapping the X server, you should at least present a strong argument against it.

Here's one: people often type Alt-BkSPC because of GNU readline defaults, and emacs defaults. Ctrl and Alt are next to each other on many keyboards, and thus easy to press together by mistake.

Now, THAT is a good reason to revisit using a single press of Ctrl-Alt-BkSPC to zap the X server.

Shortening the rope

Posted Apr 7, 2009 19:58 UTC (Tue) by nix (subscriber, #2304) [Link]

Ah, but that just makes you a member of the 'tiny minority' of Emacs
users, and GNU bash users, and GNOME users, and, oh, wait.

(I was particularly amused by the claim from the same guy that the X
developers were all Emacs users, even those who'd said 'btw, I use vim',
because they had *not explicitly disclaimed using Emacs*. So therefore
they were members of a *secret community* of *closeted Emacs users* who
were holding *secret votes* to disenfranchise the enormous community of
people who use VMs which run X and have to have X regularly force-killed
via menus that programmatically hit C-A-BS in the VM and can't be manually
configured and aren't kickstarted and can't have packages installed on
them.

It is obvious to any idiot that this latter community is *much much*
larger than the community of Emacs and bash and GNOME users.)

Correctly handling X errors

Posted Apr 4, 2009 10:32 UTC (Sat) by bockman (guest, #3650) [Link]

It has been a while since I wrote some program directly interfacing Xlib, but IIRC loosing the
connection with the X server does not directly crashes the application. Instead, the Xlib error
handling function if called - if the application had the sense to define it. This should be enough to
have - say - word processor saving a backup copy of the current document before quitting, thus
reducing the impact of CTRL-ALT-TAB.
I wonder if any application actually does this.

Correctly handling X errors

Posted Apr 6, 2009 21:43 UTC (Mon) by iabervon (subscriber, #722) [Link]

Firefox saves stuff (well, I think it saves it during normal operation rather than on exit), and emacs treats it as a "user disconnected" event and saves recovery files.

I think the real issue is not so much losing work as losing state: you're editing a particular set of documents, talking to a particular set of people, have logged into some particular web sites, and you've got the windows arranged so that you can see the windows you want at the same time. Killing the server and coming right back puts you back in a neutral state. Your word processor may save the document you were editing, but it almost certainly won't remember where your cursor was.

Shortening the rope

Posted Apr 4, 2009 10:34 UTC (Sat) by Chousuke (guest, #54562) [Link]

I don't understand why they disabled ctrl-alt-backspace entirely. There's a better way to avoid accidentally killing the X server that wouldn't cause nearly as many complaints.

On Solaris 10, a single ctrl-alt-backspace won't kill X, but three successive ones will. Anyone who wants to kill X is hopefully not going to be bothered by having to hit the key combo a couple more times.

Shortening the rope

Posted Apr 5, 2009 10:58 UTC (Sun) by marduk (subscriber, #3831) [Link]

The 3 CTRL-ALT-DEL is a good idea, but Sun likely holds a patent on it :-)

Shortening the rope

Posted Apr 4, 2009 12:25 UTC (Sat) by fb (guest, #53265) [Link]

FWIW Zsh has:

setopt NO_rm_star_silent # DO ask before executing `rm *' or `rm path/*'
setopt rm_star_wait # Wait and ignore for 10secs when 'rm *' or 'rm path/*'

Which I find rather nice to have around.

Shortening the rope

Posted Apr 6, 2009 13:28 UTC (Mon) by hppnq (guest, #14462) [Link]

That sounds like zsh's own version of rm(1), in the fine Unix tradition that each shell brings its own rope.

Shortening the rope

Posted Apr 10, 2009 13:01 UTC (Fri) by TRS-80 (guest, #1804) [Link]

It's /usr/bin/rm, the magic is in zsh's globbing which detects rm and * in the same command.

Shortening the rope

Posted Apr 14, 2009 11:58 UTC (Tue) by hppnq (guest, #14462) [Link]

Ah, thanks. What a horrible feature. A shining example of what Eric Allman -- no stranger to, err, dodgy stuff -- must have meant with his somewhat leaky screwdriver. ;-)

(There actually is a zsh module that adds an alternative rm, but it has nothing to do with this perverse behaviour.)

Shortening the rope

Posted Apr 4, 2009 19:21 UTC (Sat) by mgalgoci (guest, #24168) [Link]

Must be a slow news week, huh Jon?

Shortening the rope

Posted Apr 4, 2009 19:40 UTC (Sat) by kov (guest, #7423) [Link]

You seem to imply this is an unimportant discussion. I see it differently: this is a _very_ important
topic, that is going to become more and more important as we see GNU/Linux systems going
mainstream. We really need to figure out if we want to build usable, stable, modern systems, or if
traditions matter that much, just for being traditions.

Shortening the rope

Posted Apr 4, 2009 23:39 UTC (Sat) by Richard_J_Neill (guest, #23093) [Link]

Seems to me that Ctrl-Alt-Bksp is dangerous because you can do it by accident (it's very easy to accidentally enable sticky-keys by - hold [shift] for 8 secs), and then if you had Ctrl stuck on, and press Alt-Bksp (delete word), you've killed X by accident.

As for rm vs rm -i I personally like rm, but I think you should get the fingers into the habit of _never_ typing rm. I have an alias "cn" (for trashCaN) which moves the file into my trash. Now I never use rm in day-to-day use, and so when I do resort to it, I know that I really mean it.

Shortening the rope

Posted Apr 6, 2009 10:25 UTC (Mon) by nye (guest, #51576) [Link]

Ah, thank you!
At last that's the first believable explanation I've heard for how one might *accidentally* press a key combination which requires the use of both hands.

This has never bitten me because I always turn off any 'accessibility' features on the first occasion they enable themselves, given that they basically make the keyboard unusable.

Shortening the rope

Posted Apr 6, 2009 19:30 UTC (Mon) by nix (subscriber, #2304) [Link]

It doesn't require the use of both hands on all keyboards, anyway. (Most
common ones, sure.)

Shortening the rope

Posted Apr 7, 2009 0:39 UTC (Tue) by droundy (subscriber, #4559) [Link]

Actually, I've done this myself more times than I'd care to admit. I use alt-backspace all the time in bash (is there another word-kill key?), and on my laptop the alt and ctrl keys are adjacent, so it's very easy to accidentally hold them both down. :(

Shortening the rope

Posted Apr 9, 2009 15:38 UTC (Thu) by RobSeace (subscriber, #4435) [Link]

> is there another word-kill key?

CTRL-W is how I've always done it... CTRL-U to take out the whole line, CTRL-W to wipe just the previous word...

Shortening the rope

Posted Apr 5, 2009 19:32 UTC (Sun) by dambacher (subscriber, #1710) [Link]

Being one of these problematic emacs users I blame all those graphical console programs (kterm, gnome-terminal) to inhibit me from presing M-d to remove the last word. Instsead they open the file dialog (having a german localization "Datei") wich is really anoying.

Shortening the rope

Posted Apr 5, 2009 19:59 UTC (Sun) by dambacher (subscriber, #1710) [Link]

By the way I think , rm -r is one of the reasons why graphical destops hide the console shell program within the menu somewhere beneath
start->tools->system-tools->I-really-hope-you-wont-look-further->console.

And I accept that!

Shortening the rope

Posted Apr 6, 2009 0:28 UTC (Mon) by njs (subscriber, #40338) [Link]

gnome-terminal at least has a an option to disable those -- it's hidden under Edit -> Keyboard Shortcuts -> Enable menu access keys

Shortening the rope

Posted Apr 6, 2009 21:48 UTC (Mon) by yoe (guest, #25743) [Link]

There's a pretty useful use case for ctrl-alt-backspace: "I'm running a broken driver which fucked up my screen and now I can't do much anymore", "I'm running a broken application which first locked my screen for keyboard and/or mouse input, and now I can't do anything else anymore", etc. The ability to reinitialize a session by just killing the X server is a pretty useful feature in my opinion, which I don't want to lose.

Having said that, yes, I've also on occasion lost some data when accidentally hitting that key sequence, so I quite understand the reasons for this change.

Shortening the rope

Posted Apr 6, 2009 22:00 UTC (Mon) by nix (subscriber, #2304) [Link]

Only the 'broken driver' is a good reason (and that is more likely to
coredump the X server in my experience, which leaves you screwed 'cos the
X server is gone and can't respond to anything, or go into a tight loop,
which *also* leaves you screwed 'cos the X server isn't servicing input
anymore).

Grabs that you can't release can be broken with the server grab-breaking
key (which I really must look up).

Shortening the rope

Posted Apr 7, 2009 1:21 UTC (Tue) by bronson (subscriber, #4806) [Link]

A grab is when you type and type and click and click and nothing happens, yes? When that happens, I switch to a console and back (Ctrl-Alt-F1, Ctrl-Alt-F7 unless you're on Jaunty or F10) and usually that breaks it. If not, I switch back to the console and start hunting processes. Usually I get some innocent processes before I bag the bad guy but the damage tends to be pretty light.

If there's a keystroke that would save me the trouble I'd love to know it! Google doesn't seem to know how to release grab.

Shortening the rope

Posted Apr 7, 2009 6:25 UTC (Tue) by nix (subscriber, #2304) [Link]

X hs three major types of grabs: keyboard grabs, pointer grabs, and server
grabs. Keyboard and pointer grabs cause input (from the keyboard or the
mouse) to be directed to that window alone until the grab is released
(there are lots of options, controlling what happens to the keyboard when
the pointer is grabbed, whether to confine the pointer to the window, and
so on). You can arrange to invoke grabs after particular button presses or
releases, or particular keystrokes. This stuff is used e.g. when you hold
down a button on a menu (the grab is released when you release the button)
or when you start a selection in some text editor and yank the pointer off
the edge of the window while holding the button down: even though the
pointer is no longer in the window, pointer events are still going to the
window. That's a grab.

If the application fails to release the grab, events will keep going to
that window, and it's likely to get rather confused (plus, of course,
events won't go anywhere else so you'll be a bit messed up).

Server grabs are much harsher. If you grab the X server, all connections
other than the grabbed connection are ignored until the server is
ungrabbed. This strikes me as a terribly bad idea (if the grab isn't
released sharpish it's indistinguishable from a server lockup). I'm not
sure why this request even exists. Anyone know? What use is it?

... regarding breaking grabs, I can't find the documentation or code for
this feature in recent xorg-xserver trees. Maybe I dreamed it...

Shortening the rope

Posted Apr 7, 2009 11:54 UTC (Tue) by nix (subscriber, #2304) [Link]

Hah! No! See <https://www.redhat.com/archives/fedora-devel-list/2009-Ma...>.

Gone in xserver 1.6 though.

Shortening the rope

Posted Apr 10, 2009 4:49 UTC (Fri) by njs (subscriber, #40338) [Link]

>I'm not sure why this request even exists. Anyone know? What use is it?

Because it's how you say "perform this sequence of operations atomically". The most recent example I happen to have seen is in the XSETTINGS spec where it notes you need a server grab at one point to avoid a race condition, but just in general, X is all about multiple apps working in parallel on a bunch of shared state, and sometimes you need a locking primitive.

It's also used for various hacks (e.g. if your wm does rubber-band resizes, it'll grab the server to prevent other windows redrawing themselves over the rubber band, apps that want you to enter a password will sometimes grab the server to prevent shenanigans, ...).

Shortening the rope

Posted Apr 9, 2009 0:20 UTC (Thu) by smadu2 (guest, #54943) [Link]

Why does killing X should case data loss ? And if cntrl Alt Bkspace is to restart X then is there an option to restore my previous X session ? I guess I am being naive.

Shortening the rope

Posted Apr 9, 2009 7:17 UTC (Thu) by hppnq (guest, #14462) [Link]

Session management does not start processes in the state they had when they were last stopped, unless this happens to be a feature of a particular application (e.g., Firefox is able to reload tabs). All data that is not recoverable by the applications that went down with the X server, is lost.

Shortening the rope

Posted Apr 9, 2009 8:58 UTC (Thu) by smadu2 (guest, #54943) [Link]

Thanks, makes sense. The feature FF has is neat, I never have to worry about loosing my FF tabs when shutting down/reboot etc. It would be good if more apps behaved that way.

Shortening the rope

Posted Apr 17, 2009 12:17 UTC (Fri) by Ross (guest, #4065) [Link]

Except that if FF crashes while recovering after a crash (due to some strange Javascript in one of the
tabs), it sometimes corrupts the tabs and isn't able to recover again :(

This has happened to me twice. Seems like the browser could save the tab list to a separate
directory and do an atomic (1) rename. I hate to see the same mistakes made over and over in
every code base.

(1) except this won't work on ext4 or ext3 in writeback mode as seen in recent dicussions

I've done it by accident

Posted Apr 9, 2009 13:37 UTC (Thu) by scjody (guest, #55326) [Link]

I actually did press Ctrl-Alt-Backspace last week by accident while running EMACS. I meant to press Ctrl-Alt-\, which is indent-region. I think that's actually a default binding, so I'd be surprised if I'm the first to do it.

I've since changed the binding in my .emacs.

Nanny state frivolity

Posted Apr 9, 2009 22:37 UTC (Thu) by dw (subscriber, #12017) [Link]

Can we expect --preserve-lib option being the default for mv in 10 years time? I'm utterly shocked at the existence of the change to rm. Not even that, but at how fragile it is it's literally just doing a strcmp?

As for the CTRL+ALT+BACKSP thing. I've killed my X session tonnes of times with it, but the value of having it outweighs the occasional accidental loss of session (roughly about as often as a power outage occurs anyway).

I suspect if someone suggested, rather than a 1 line patch to disable the 3 finger salute by default, a 100 line patch to put a window on screen with a warning, request to press it 2 more times, or hold the keys down for 3 seconds, people would just shut the hell up when they realized there's at least one solution to this problem that involves actual work rather than constant whining.

Nanny state frivolity

Posted Apr 17, 2009 20:12 UTC (Fri) by nix (subscriber, #2304) [Link]

rm --preserve-root doesn't do a strcmp(), it compares the device and inode
number of the to-be-removed entity with that of /.

(Why does nobody read the source? It's there and not hard to read: this
took me less than a minute to figure out. Is unfounded speculation just
more fun or something?)

Shortening the rope

Posted Apr 11, 2009 20:55 UTC (Sat) by mdz@debian.org (guest, #14112) [Link]

Correction:

Ubuntu developers did not change the default for --preserve-root. This change was made upstream in GNU coreutils, and we inherited it from them via Debian. This should be fairly clear from this comment.

From the coreutils ChangeLog:

2006-09-02  Paul Eggert  <eggert@cs.ucla.edu>
[...]
        * src/rm.c (usage, main): --preserve-root is now the default.

I assume that the same happened in Fedora, and will be true of any distribution shipping a modern version of coreutils.

For what it's worth, I personally think the change is appropriate, but it is incorrect to attribute the change to Ubuntu developers.

Shortening the rope

Posted Apr 17, 2009 3:53 UTC (Fri) by ccurtis (guest, #49713) [Link]

I expect I'll never get a response in a thread this large, but I'm a bit confused here - I think there's a problem in the analogy. Having enough rope to hangs one's self is one thing, but then adding extra rope tends not to increase the likelihood of a successful hanging...

Or is this just another one of those things where the more unbelievable something is the greater the worth being assigned to it through invariably larger caches of salt, and I should just silently bemoan to myself this lack of any actual rational meaning in the ongoing evolution of language?

Shortening the rope

Posted Apr 18, 2009 2:23 UTC (Sat) by Kit (guest, #55925) [Link]

'Enough rope to hang one's self' isn't really an analogy, but more so a figure of speech. The 'and then a couple of more feet, just to be sure' was really just a joke meant to point out how Unix gives the user many ways to hang one's self. 'Shortening the rope', on the other hand, is a play on that to mean reducing the amount of ways one can hang one's self.

Aliasing rm by default

Posted Apr 17, 2009 11:28 UTC (Fri) by Ross (guest, #4065) [Link]

> If so, one should certainly complain about the much more obnoxious
>
> alias rm='rm -i'
> .bashrc entries that Fedora has been inflicting on the root account for years.

Oh I certainly have :) That's the first thing to go on any RH system I manage.

It annoys me because it leads to errors when I'm not expecting a prompt and I'm already typing
another command, and the quick workaround of using -f is more dangerous.