26

I don't really understand the linux clipboard/s scheme. Instead of understanding it, is there a way to simplify it into one, unified clipboard? You know, so I could copy in any app and paste in any other?

The current issue that's bugging me is IntelliJ's "copy path" action seems to copy the path of the current file, but I can only paste it back into IntelliJ itself - if I try to paste it into a terminal, the content simply isn't in the clipboard.

imz -- Ivan Zakharyaschev
  • 15,462
ripper234
  • 31,763
  • Never used that IDE, but I don't have any issues with the Linux clipboard. Are there other sch situations? – tshepang May 22 '11 at 13:42
  • 1
    @Tshepang - one example is in gvim, if I select a text, do edit-->copy, then select another piece of text, then I effectively have two different pieces of text to paste. Middle click will paste the last text I selected, while edit->paste will paste the text I edit->copied. – ripper234 May 22 '11 at 14:19
  • There is concept of clipboard in the X Window system. Given that most of the time you work in X, this is only a matter of configuring/patching programs not using X clipboard to use it. For example, X-window enabled GNU Emacs don't copy to X clipboard by default, but can be easily configured to do so. – alex May 22 '11 at 15:01
  • @alex Not exactly true, there are multiple concepts of clipboard in the X Window System. – Adam Byrtek May 22 '11 at 18:30
  • 1
    @ripper234: That's because Vim by default copies to its internal buffer. If you want to copy to the system clipboard, use the + special buffer, to copy "+y and to paste "+p in the Command Mode. The * buffer is the middle click buffer, and there are many regular buffers which can only be used by Vim which can be accessed by prefixing the copy/paste with "a to "b (e.g. "aY) – Lie Ryan May 22 '11 at 18:38
  • @Lie what ripper234 said is correct. In gvim the menu action copy is the same as "+y. However the fact that vim has its own internal "clipboard" only puts more emphasis on the fact there are multiple clipboards, even if some are software specific, hence the confusion. – unode May 23 '11 at 01:36

3 Answers3

14

There are several clipboard managers such as parcellite, klipper, glipper, glippy, anamnesis, pastie and others. These generally allow you to manage your clipboard by presenting a history.

Some of them allow you to treat the primary and secondary clipboards as one (parcellite and klipper definitely do).

Anamnesis allows you to plow through your history with a search tool.

Shawn J. Goff
  • 46,081
4

autocutsel is a lightweight tool that merges the contents of both clipboards. You might also consider using a full-blown clipboard manager, like Shawn suggested.

Adam Byrtek
  • 1,339
3

Presumably, you are trying to paste into the Terminal using middle-click.

Generally speaking, if you Copy with the application menu, context menu (which usually just triggers the application menu), or ^c (which also usually triggers the app menu), the results are stored to the "Clipboard" selection and can be Pasted with ^v or a corresponding menu.

If you Copy by highlighting text with the mouse, the results are stored to the "Primary" selection and can be Pasted by middle-clicking the target window.

If you select text in your application with the mouse, then use ^c to Copy it manually, you will stored the results in the "Primary" selection with the mouse, and the "Clipboard" selection with the ^c, so they will both match and you don't get confused.

But, if you select text in your app with the keyboard, then hit ^c, and subsequently select some other text (like a target selection to overwrite) the result will not be stored in the "Primary" selection and you will not get the copied text. You will not be able to middle-click to Paste the copied text, but you can use the Terminal application menu or context menu to Paste from the "Clipboard" selection.

Some applications will also fill the "Primary" selection when you Copy to the "Clipboard". This is non-standard behavior and should be avoided and not relied upon.

Rich Remer
  • 139