Hi there, I think I'm having the same problem. I collected some information and would like to share.
First, my system:
- Host OS: Windows 7 pro 64 bits
VirtualBox 4.08
Intel VT-X disabled in BIOS
Guest OS: Arch Linux 32 bits
VirtualBox Guest Additions 4.0.8-4 (Arch package installed with ArchWiki directives)
Wrapping up the thread so far, we're talking about a virtualbox problem that seems to be a limitation of the shared clipboard feature.
First, we discard the following issues which could lead to similar effects described in the above thread:
- - VirtualBox Shared Clipboard has not been set to bidirectional.
- VirtualBox Guest Additions has not been installed on the the guest OS.
- Linux distro-specific directives has not been followed correctly.
As far as I read information on similar problems, what GrAal is reporting is not specific to XTerm but rather in the way X server and the different X-client-applications running on it handle the "clipboards". Let's clear up the naming of the distinctive "clipboards". In Linux, we could find 3 different ones (quoting Wikipedia article on X Window Selection)
- 1. PRIMARY selection (used when the user selects some data)
2. CLIPBOARD selection (used when the user selects some data and explicitly requests it to be "copied" to the clipboard, such as by invoking "Copy" under the "Edit" menu of an application. This implies keyboard-bindings to these commands like ctrl-c and ctrl-v.)
3. CUT_BUFFERS (Obsolete. I don't think the actual problem is related to that. See the Wikipedia article for further information)
The interesting part is:
At the level of the (X) core protocol, the PRIMARY and CLIPBOARD selections do not differ. But the xclipboard client makes them behave differently. In particular, when another client asserts the ownership of the CLIPBOARD selection, this program requests and displays it in a window. Any further request for this selection are handled by xclipboard. This way, the content of the selection survives the client having copied it.
http://en.wikipedia.org/wiki/X_Window_s ... #Clipboard
In other words, the CLIPBOARD selection behaves differently from one application to another. This could explain the fact of having our shared clipboard problem with some applications and not with others because VirtualBox only use the CLIPBOARD selection so far. If there's a way of changing this, I would like to know. The problem occurs depending if the application uses the CLIPBOARD selection or not. It could also occurs if the application uses the CLIPBOARD selection in a non-standard way. As far as I know, I think the PRIMARY selection is managed by X itself and works the same way in all guest applications. The real problem (the one for which this thread was created) is that VirtualBox doesn't use the PRIMARY selection and you cannot paste in the host using this method. In the other hand, the CLIPBOARD selection can be pasted in the host. However, you have to hassle with the differences between applications.
GEdit works fine from the defaults. You can copy in guest/gedit with
crtl-c and paste in host/notepad with
ctrl-v.
In many terminals like gnome-terminal, you can copy with
ctrl-shift-c with no customization.
I don't know for Firefox but if you use Iceweasel, it uses only PRIMARY selection.
With the initial default configuration of some applications, it doesn't work (e.g. XTerm)
Workarounds exist (I didn't find the ideal solution yet as it would be that VBOX use PRIMARY selection).
- - Application customization (differs, e.g. XTerm and Emacs)
- Clipboard managers
As it was proposed for XTerm, some applications allow customizations of the way they handle the "clipboards". The following worked for me. To keep it simple, it tells XTerm to copy the PRIMARY selection to CLIPBOARD selection which can be pasted in the host.
for the Copy & Paste functionality one simply needs to add the following line to the ~/.Xresources file:
Code: Select all
XTerm*VT100.translations: #override <Btn1Up>: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)
You can test it with an xterm:
Code: Select all
xterm -xrm 'XTerm*VT100.translations: #override <Btn1Up>: select-end(PRIMARY, CLIPBOARD, CUT_BUFFER0)'
There are also clipboard managers like Glipper, Klipper, Parcellite which keep the 2 "clipboards" in sync at all time. However, I read that these tools doesn't offer enough control yet to be perfect. The major inconvenient of clipboards syncing is when one would like to select data and replace it with the clipboard content. The former action will instead cause the clipboard content to be overwritten by the selection.
In text editor applications like gedit, one might want to control the clipboard explicitly with
ctrl-c and
ctrl-v and enable the PRIMARY selection control only in terminals.
I have to try to know if this really bugs me. Is anybody tried clipboard managers already?
I hope I convince you of removing XTerm from the title
I wish this post helps someone to quickly understand, diagnose and find a solution that fits his need.
Maybe someday we'll be able to configure VBOX to use PRIMARY selection.
at last.