A brief history of cut and paste in X
Here's a brief history and explanation of how cut and paste works in the X Windows system (to give it its formal name), prompted by this blog entry with the entirely reasonable gripe that selecting something in a program and then exiting the program causes the selection to disappear.
There are two separate cut and paste mechanisms in X, from two separate
eras: the cut buffer and selections.
The cut buffer is the older mechanism, and works by having programs store
the cut data into an X property on the root window, which you can see
directly with '
xprop -root CUT_BUFFER0'. (Technically there are
eight or so cut buffers, but almost no one uses anything except the
The cut buffer has some limitations:
- it doesn't handle large amounts of data, because it stores things in X properties.
- it only really handles text, and text without character set information at that.
- you can only make the data available in one representation, when it may have several possible ones.
These were fine as long as the X was mostly used to run
xclock (to swipe a slam from the Unix-Haters Handbook), but not so good when people started trying to do
more sophisticated things. Enter selections.
Selections solve the cut buffer limitations by making the program that generated the selection hold onto the selection itself. When other programs want to paste something, they talk to the holding program directly to get a copy, and negotiate things like what format it's going to be in.
The drawback of the selection model is what Martin Krafft experienced: if the program that set up a selection goes away, so does the selection, because no one else has a copy. (In fact the creating program can make the selection go away any time it feels like, and often has to take extra steps to take a private copy just for the selection.)
As a pragmatic matter, any program that selects text should export the selection into the cut buffer and anything that can paste text in should read from the cut buffer if there's no current selection, because that avoids most of the problem. Unfortunately there has been something of a movement for ignoring the cut buffer as 'obsolete', so things like Firefox and gnome-terminal never go near it.
(A more complete technical explanation is in Jamie Zawinski's X Selections, Cut Buffers, and Kill Rings.)
Sidebar: selections and the clipboard
The clipboard is effectively a second selection; it uses the same mechanisms and also goes away when the owning program exits. What shows up in the clipboard versus what is just a plain selection depends on the application, but the general rule is that copying or selecting something explicitly will make it into the clipboard instead of a mere selection. For most purposes you can ignore the difference.
xclipboard program keeps a copy of the clipboard contents, which
can sometimes be convenient. It also makes a handy text window to
scribble stuff in.
xselection program is possible, but I don't know if
anyone's already written it. It might cause significantly more X traffic
and CPU usage, since programs change the selection a fair bit more than
they change the clipboard.)