Reputation: 5449
I have problem with bindings in tmux 1.8.
Problem appear when I type command which run shell For example:
bind y run-shell "tmux show-buffer | xclip -sel clip -i"
And i type y After execution command, tmux not respond on any other bindings (for example w) It may take a few minutes and then you can use bindings.
what could be the problem? It appeared in version 1.8 (with version 1.7 all ok) OS Ubuntu 13.04(64)
Upvotes: 6
Views: 4031
Reputation: 1183
It seems 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 /await xclip's termination, thereby rendering the window manager unresponsive.
source:https://wiki.archlinux.org/index.php/Tmux#X_clipboard_integration
Piping the output to /dev/null
should fix it:
bind y run-shell "tmux show-buffer | xclip -sel clip -i > /dev/null"
See https://stackoverflow.com/a/21190234/109282 for more info.
Upvotes: 14
Reputation: 159
Just changing 'tmux show-buffer' to 'tmux save-buffer -' generally improved tmux' behaviour for me in these circumstances. 'show-buffer' redirected to a file was hanging indefinitely for me, and also piping it to xclip was causing unwanted wrapping of long lines, whereas 'save-buffer -' (as per the thread linked by G Mawr) works perfectly.
I suspect because 'show-buffer' assumes it's talking to a terminal, and 'save-buffer' does not.
E.T.A. I'm using tmux-1.6-3, so relevance may be limited.
Upvotes: 0
Reputation: 21
The problem is that tmux is waiting for that command to return, and it hangs. This effectively locks you from executing any tmux commands. I got around this problem by adding -b after run-shell which makes the commands run in the background. A problem is that those processes hang around, so this isn't a perfect solution.
Another way around this problem is to close the window and reattach the session.
Upvotes: 2