A mismash of bugs and workarounds causes the copy buffer (X selection) to get wiped some of the time in my recent desktop environment. And that in a seemingly unpredictable manner.

The following bug is mostly in play: GNOME VTE soft reset wipes selection

That bug causes:

  1. reset(1) to wipe the middle-mouse (primary) buffer (although this differs per system — could not put my finger on this);
  2. reset(1) to wipe the clipboard buffer, but only if the reset was called from window that originated the current clipboard buffer contents;
  3. GNU screen(1) initialization to misbehave as reset does, as described above — even through an ssh session — by wiping the buffer, if TERM=xterm-256color.

To add to the confusion, the fix from debian bug 134198 has masked the problem for screen, for as long as the TERM environment has been set to 'xterm'.

You can probably reproduce by simply echoing (part of) the init_string2:

$ TERM=xterm infocmp -1 -C | grep :is=
        :is=\E[!p\E[?3;4l\E[4l\E>:\
$ printf '\x1b[!p'

At this point one or more of your copy buffers may be wiped. Although the effects appear to be worse on my Ubuntu/Artful than on Zesty.

Madness. Well at least now you know where to look when your copy buffer is wiped.

copypaste screen selection terminfo