9

On mu Ubuntu 12.04 setups my tmux clipboard copy and paste commands are setup as follows:

set -g prefix M-a
unbind C-b
bind C-c run "tmux save-buffer - | xclip -i -sel clipboard"
bind C-v run "tmux set-buffer \"$(xclip -o -sel clipboard)\"; tmux paste-buffer"

This worked great for the longest time up until a month or so ago, when I suspect some configuration change or package change was made that broke the above. In GNOME terminal, pasting still works fine with both prefix+ctrl-v and ctrl-shift-v.

However the xclip copy command no longer works no matter what I do, and I have tried removing the custom prefix binding above, using -select instead of -sel, not using clipboard etc. This is pretty much a show stopper for a GVim user like me, since I don't even have the GNOME terminal workaround of ctrl-shift-c with tmux taking over the shell. I go into copy mode, select text with space+movement, and when I execute prefix+ctrl-c absolutely nothing happens. Before this broke, tmux would display a confirmation message in the notification section at the bottom.

Does anybody have suggestions as far as how one might debug this? This is a pretty big productivity hit. I can probably use the temporary file workaround trick for now, but it'd be great to know just what happened to xclip.

Community
  • 1
Alexandr Kurilin
  • 2,481

6 Answers6

10

The xsel utility is similar to xclip, but implemented a little differently. Normally I would expect them to behave in the same way, but they don't make exactly the same X library call, so it's possible that in some corner cases xsel will work but not xclip, or vice versa. Try:

bind C-c run "tmux save-buffer - | xsel -ib"
bind C-v run "tmux set-buffer \"$(xsel -ob)\"; tmux paste-buffer"
Gilles 'SO- stop being evil'
  • 829,060
  • The same result - do not works for me - works as standalone command but return empty string from such bind; Ubuntu 14.04, xsel 1.2.0, tmux 1.8-5 – Vitaly Zdanevich Mar 11 '17 at 06:58
6

Adding -b to run-shell (or run) command fixed the problem. With -b the shell command is run in the background.

bind C-c run-shell -b "tmux save-buffer - | xclip -i -sel clipboard"

Pawka
  • 161
2

Although I can't reproduce it anymore but here's the technical answer what might have happened in your case.

First, you need to understand how X11 clipboard works. You might read jwz's essay on this: http://www.jwz.org/doc/x-cut-and-paste.html

In short, the application which holds the contents of the clipboard needs to run until other application asserts the ownership. So when you run xclip -i <<< test then you can see xclip running in the background until you make another selection:

$ xclip -i <<< test
$ ps
  PID TTY          TIME CMD
10166 pts/8    00:00:00 xclip
10171 pts/8    00:00:00 ps
19345 pts/8    00:00:00 bash

Now this is all fine but when you exit this shell then all processes belonging to this session are killed by default by sending them a HUP signal. This will mean xclip will be killed and you won't be able access your clipboard contents anymore.

So the suggested workaround (in case you don't have xsel) is to ignore the HUP signal by using the following bind:

bind C-c run "tmux save-buffer - | nohup >/dev/null 2>/dev/null xclip -i -sel clipboard"

xsel is not affected by this problem because the first thing it does after the fork() is to disassociate itself from the controlling terminal so it won't receive the HUP signal when its shell exits (you won't even see it in the above ps output but only when you do a ps -e | grep xsel).

ypsu
  • 261
1

This is an old question, but I suspect I have the solution, taken from the Tmux page of the Arch wiki:

xclip could also be used for that purpose, unlike xsel it works better on printing raw bitstream that doesn't fit the current locale. Nevertheless, it is neater to use xsel instead of xclip, because xclip does not close STDOUT after it has read from tmux's buffer. As such, tmux doesn't know that the copy task has completed, and continues to wait for xclip's termination, thereby rendering tmux unresponsive. A workaround is to redirect STDOUT of xclip to /dev/null

So your command should become:

bind C-c run "tmux save-buffer - | xclip -i -sel clipboard >/dev/null"
PlasmaBinturong
  • 619
1

I'm experiencing a similar problem and the temporary file won't help in this particular case, I'm afraid. This is because xclip seems to behave differently when spawned by tmux than when being run "interactively" and waits for another application to take ownership of the clipboard area. Try using xclip -l 1 to make it quit immediately (see man page for details).

peterph
  • 30,838
  • Can't seem to get that work work. Is this what that binding should look like: bind C-c run "tmux save-buffer - | xclip -l 1 -i -sel clipboard" ? – Alexandr Kurilin May 28 '13 at 17:41
  • Could you perhaps post what workaround worked for you? That'd be pretty helpful as well! – Alexandr Kurilin May 28 '13 at 17:51
  • I'm using bind C-y run-shell "tmux save-buffer - | xclip -l 1 -i". – peterph May 28 '13 at 21:04
  • Yeah, still nothing unfortunately. Tmux doesn't report anything, nor does xclip. – Alexandr Kurilin May 29 '13 at 00:17
  • For me it's not reporting anything either, but it works. Check what xclip is doing when you try to copy the buffer. If it stays hanging there waiting for something, does killing it help? Also, you have to exit the selection mode by hitting Enter (and hence storing it into buffer) before you try to copy the buffer into the X clipboard. – peterph May 29 '13 at 09:36
  • I followed the steps you recommended, selected and exited the selection mode with Enter, and then ran the command above. A quick "ps aux | grep xclip" does seem to reveal that xclip starts and hangs in there every time I run that command. Killing the process doesn't seem to do much as far as I can tell. – Alexandr Kurilin May 29 '13 at 20:25
  • @AlexandrKurilin It's normal for an xclip process to stick around after setting the clipboard content: the clipboard content is kept in the copying application, not in the X server, so the copying application needs to stick around until some other process sets the clipboard content to a new value. – Gilles 'SO- stop being evil' May 29 '13 at 23:58
  • @AlexandrKurilin I've found that my clipboard manager (which I somehow let live inside of my sessions) was interfering - maybe you enabled/disabled something like that and changed slightly the behaviour of the whole clipboard system? – peterph May 30 '13 at 08:19
  • @peterph I'm not sure I have one, unless it comes by default in Ubuntu 12.04. What app should I check for to see if one exists? – Alexandr Kurilin May 30 '13 at 19:06
  • I guess there is a plethora of those, xclipboard and parcellite are two examples. – peterph Jun 02 '13 at 23:07
0

This is a working configuration I use:

# Yank to copy text with y.
bind-key -t vi-copy y copy-pipe "tmux save-buffer - | xclip -sel clipboard -i"

# Update default binding of `Enter` to also copy with this method.
unbind -t vi-copy Enter
bind-key -t vi-copy Enter copy-pipe "tmux save-buffer - | xclip -sel clipboard -i"

# Toggle rectangular copy mode.
bind-key -t vi-copy 'C-v' rectangle-toggle

# Bind ']' to paste.
bind ] run "tmux set-buffer \"$(xclip -o -sel clipboard)\" && tmux paste-buffer"

# Toggle rectangular copy mode.
bind-key -t vi-copy 'C-v' rectangle-toggle

# http://askubuntu.com/a/507215/413683
set -g set-clipboard off
Mateusz Piotrowski
  • 4,773