This was also answered here, but it took me a while to understand how to use it, so I'll explain for anyone else that was confused.
This is basically the setting you're going for:
(for tmux versions <2.5)
bind -t vi-copy y copy-pipe 'xclip -in -selection clipboard'
(for tmux versions >=2.5)
bind -T copy-mode-vi y send-keys -X copy-pipe-and-cancel '...
As it turns out, the link in the question hinted at a working solution in the form of xclip:
pandoc -S file.mkd | xclip -t text/html
...and then I can paste it straight into the document in libreoffice, properly formatted. This works with the versions of the programs in the Ubuntu 13.04 repositories (pandoc 1.10.1 and xclip 0.12) -- the -t option for xclip ...
Here is an attempt at a comprehensive answer.
First a little history
When this question was first asked (June, 2011) copying text from Tmux to the clipboard had to be a two-step process, first copy the selected text to Tmux's buffer, then copy the text from Tmux's buffer to the system clipboard.
In 1.8 (March, 2013) the copy-pipe command was added which ...
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 \"$(...
Take a look at the tmux-yank plugin for tmux.
It provides an automated way to copy/paste from tmux to the system clipboard. It works on OSX/Linux/Cygwin systems.
If using xterm or a derivative you can setup key bindings to start and end a text selection, and save it as the X11 primary selection or a cutbuffer. See man xterm. For example, add to your ~/.Xdefaults:
<Key>KP_1: select-cursor-start() \
You are running into a couple of technical issues:
The “special mode” bindings (e.g. vi-copy) …
use a different set of commands (i.e. run-shell a.k.a. run is not available), and
do not have the ability to bind multiple commands (which can normally be separated by ;—the shell’s && command separator is not available).
tmux 1.8 has copy-pipe, which ...
X doesn't really have a "clipboard" by default. Selections are managed by the application that "owns" them, and if you want to copy or paste a selection, this is done by communication between both applications, which means the other application that holds the selection must still be running.
There is however a method to take over a selection, so there are ...
I tried a bunch of stuff here and there, but this is what worked form me in my ~/.tmux.conf file I am using Ubuntu 20 LTS and tmux3.0a
#for copying to sys clipboard
bind -T copy-mode-vi Enter send-keys -X copy-pipe-and-cancel "xclip -i -f -selection primary | xclip -i -selection clipboard"
bind -T copy-mode-vi MouseDragEnd1Pane send-keys -X copy-...
I wrote a tool which returns the plain application name (e.g. 'Terminal', 'gedit' or 'SmartGit' which are the ones I tested). Most code is shamelessly stolen from @Harvey here.
// gcc clipboard-owner.c -lX11 -o clipboard-owner
I copied an image into clipboard with xclip like you did and here's what list of targets I got:
> xclip -selection clip -t TARGETS -o
and now if I copy an image from a web page I get this:
> xclip -selection clip -t TARGETS -o
This is my rather lengthy answer that should fix two major problems with using xclip to copy the buffer from a remote (ssh) tmux session:
1. Irresponsive xclip
For me @Grauwolf's answer with xclip didn't work (renders tmux pane totally irresponsive).
I found out why in the Tmux page of the Arch wiki:
xclip could also be used for that purpose, unlike ...
:'<,'>!xclip && eval "$(xclip -o)"
runs perfectly fine in my test (Ubuntu 16.04 LTS, with bash 4.3, vim 7.4), and transforms the 4 lines to a single character 'f'. Replacing && with | also works although it is not recommended.
I don't think running shell commands with vim is very different from running in the usual shell, and it ...
Use sed to remove everything after and including the first dot:
:nnoremap yn :!sed "s/\..*//"<<<%c|xclip -selection clipboard %i<cr>
If your shell does not support herestrings (<<<), use printf
(Why is printf better than echo?) to pipe into sed:
:nnoremap yn :!printf '%%s' %c|sed "s/\..*//"|xclip -selection ...
The author of the original question on Stackoverflow has identified this to be a problem in xclip. Using xsel instead of xclip for manipulating the X clipboard eliminates the issue (note that xclip was replaced with xsel only when placing data into the clipboard, and not when reading from the clipboard):
$ cat xclip_test
Actually, there is no X "system clipboard". Selections in X work by two X clients cooperating: One X client claims it has an selection (primary, secondary, clipboard), and another X client that wants to paste the selection contacts the first client to receive it.
So when the first client is dead, there's no selection. I'm not sure how bash interactive mode ...
xclip uses the X Toolkit library, which does the options-parsing. All of the options can be abbreviated. The library only gives an error if there is an ambiguity.
Options, of course, are things like -select which can be abbreviated as -sel (possibly even -s).
xterm uses the same library, same behavior. It uses special cases (outside the library) to make ...
On Wayland, instead of xclip, better use wl-copy/wl-paste of wl-clipboard package. This works for me:
set-window-option -g mode-keys vi
bind-key -T copy-mode-vi 'v' send-keys -X begin-selection
bind-key -T copy-mode-vi 'y' send-keys -X copy-pipe-and-cancel "wl-copy"
bind C-p run "wl-paste --no-newline | tmux load-buffer - ; tmux paste-buffer"
update: since ...
Many of these answers didn't work for my Ubuntu 14.04 on zsh as-is. Not sure if my shell had anything to do with it, but here is my working version of using this strategy for copy, and this strategy for paste.
bind-key -t vi-copy 'v' begin-selection
bind-key -t vi-copy 'y' copy-pipe "xclip -sel clip -i"
bind-key ] run-shell "xclip -sel clip -o | ...
This typically happens with programs that implement multiple behaviors and decide on which one to act by inspecting the name by which they were called.
This technique is used in some popular tools such as busybox which provides most of the typical Linux/Unix standard utilities in a single binary.
In this case, it seems the same binary is implementing both ...
This is what ended up working for me using tmux 2.2 and having installed xclip.
For Vim style copying add the following to .tmux.conf
bind Escape copy-mode
bind -t vi-copy 'v' begin-selection
bind -t vi-copy 'y' copy-selection
# Vim style copy to clipboard
bind-key -t vi-copy y copy-pipe "xclip -selection c > /dev/null"
bind-key p run "xclip -o -sel clip ...
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 ...
You could assign a shortcut to a command like:
xclip -o -sel p | tr '[:lower:][:upper:]' '[:upper:][:lower:]' | xclip -i -sel c; xdotool key Shift+Insert
This assumes Shift+Insert pastes from clipboard (if that's not the case, replace Shift+Insert with ctrl+v). It pipes the text from the primary selection to tr, overwrites the clipboard selection with the ...
I also stumbled upon this issue. After some googling I found the solution on a japanese blog here.
Instead of doing bind-key -t vi-copy y copy-pipe "xclip -sel clip -i"
Do something like this:
bind-key -T copy-mode-vi y send -X copy-pipe "xclip -sel clip -i"