I'm glad I'm not the only this has effected. Why is this taking so long to fix? Could it be because traditional linux users don't want to lose the clipboard integration that they put into the terminal emulator? I'd bet so. This is unacceptable. Here's a write up of a frustrated linux user who tried to use the clipboard in linux from http://elliotth.blogspot.com/2008/08/desktop-linux-suckage-clipboard.html. Desktop Linux suckage: the clipboard X11's equivalent of the clipboard has been broken since I first used X11, back in 1993. 15 years later, things are still as bad as ever they were. They say hard cases make bad law, and terminal emulators make very hard UI cases. Unfortunately, nerds being nerds, a terminal emulator tends to be the first application written for any Unix GUI. There are two main problems caused by starting with the terminal emulator and generalizing to the other 99% of applications. The more fundamental problem is that terminal emulators expect that most keystrokes can be passed through to the pseudo terminal, including the keystrokes that every other application on your system uses as keyboard equivalents for menu actions. The X11-specific problem is that XTerm conditioned many long-term Unix users to use the selection instead of the clipboard. (If you're not an X11 user, you probably have no idea what I'm talking about here. Don't worry; we'll get to it.) The big problem with the X11 clipboard is actually nothing to do with terminal emulators, except in so far as if they'd actually written some real apps instead of guessing what they might be and how they might behave, they probably wouldn't have crippled the clipboard in the way they did. The easy one first, though. Mac OS uses a modifier key for menu actions (the "command" key) that didn't exist on traditional terminals, cleverly side-stepping the problem. PuTTY on Windows basically does without; a not unreasonable solution. GNOME Terminal uses control and shift (instead of just the "control" key). Terminator uses alt, which used to be popular on Unix, but fell out of favor in Linux times, thanks (I've always assumed) to the influx of Windows users. As for the second problem, you may or may not know that Mac OS actually has multiple "pasteboards" (as usual, even their terminology is different). Mac OS hides them well enough that real people neither know nor care. Real people using Linux, even if they only use Firefox, get screwed by the old "selection" versus "clipboard" nonsense. Basically, in addition to the usual clipboard with its explicit "copy" and "paste" actions, there's a "selection". To set it you just select some text. To paste it, you press the middle button. (These days, the scroll wheel.) To paste it over existing text (such as in your web browser's location bar)... well, you can't do that. It's roughly that mistake that screws people over. I see this catch people out at least once a week, and that's amongst X11 users savvy enough to simply shrug, mutter something along the lines of "bloody clipboard", and try again more carefully. As long Linux has no Steve Jobs to stand up and say "this is hurting us, so out it goes", I don't see this getting fixed. Anyone could write the patches to remove X11 selection support. But without a Steve Jobs standing over the relevant projects' maintainers, how could we ever get them accepted? The gatekeepers we have are the XTerm-toting Emacs users who sincerely believe they couldn't live without this shit. (KDE offers an option to ignore the selection, but I believe it defaults to the old behavior. My work-around is to just never use middle-button paste. It's a lot easier to kick the habit than most old-timers probably imagine, and it makes your muscle memory more portable to other systems.) This isn't actually the worst part, though. The funny thing about that nonsense is that it's more likely to affect nerds than real people, because real people aren't too likely to come across the selection by accident. In fact, they're likely to give up on Linux before they get that far. More serious is that there isn't a clipboard in the sense of a central place that stuff gets copied or cut to. The way it works is that it's more like a token that gets handed round. So if you copy in Firefox and paste Rhythmbox, what happened was that at copy-time Firefox said "if anyone wants the contents of the clipboard, they should ask me", and at paste time Rhythmbox asked "who has the clipboard contents?", was told "Firefox", and asked Firefox "could I have the clipboard contents?". Which is all nice and efficient, saving unnecessary copying... until someone copies, quits, and tries to paste. Now the application with the data is no longer running, so it's gone. This is not how a clipboard should work. I don't need to tell you that this isn't how a clipboard should work, of course. You have common sense. You're not a paranoid engineer engineering for the worst case (of copying a 2GiB MPEG movie onto the clipboard) and completely ignoring the more common case (of copying 28 characters of text onto the clipboard). Unfortunately, the guys who got here first were paranoid, unrealistic, and broke the system to "protect" it against the possibility of ill-behaved applications. (Java, despite its Solaris/X11 heritage, comes across as if it believes in the Windows model. So in a Java application, you can't really avoid the copying; the JDK will do it for you. You just don't get any benefit out of it. The lesson toolkit designers seem unwilling to learn, and this applies to modern-day criminals as much as the X11 80s beard crew, is that you can't force applications to behave the way you want. So forget about "all". How do you get 99% to behave well? You give them sensible behavior for free. 99% will take the default behavior, and the other 1% were lost anyway. Fearing and focusing on the 1% makes you about as smart as the TSA, and almost as annoying.) Problem: we're still living with bad design decisions from the 1980s, and there's neither the will nor the power to get them fixed.