Additionally, the “trick” I use is to always use a tmux session on the remote machine, via byobu (I do all my work inside tmux sessions—even on my local machine). That means even if you do end up killing the ssh session for whatever reason, your work on the remote machine does not suffer. The tmux session simply gets detached, and when you connect later, you can continue where you left off. This is particularly useful when running upgrades—losing connectivity and killing the upgrade can mess up systems.
Did they somehow fix the “screen/tmux breaks terminal scrollback” thing that’s always prevented me from doing that as a matter of course? Because I agree, it would be great, if it didn’t mean that I can’t just grab my mouse and spin the wheel to look at the session output history.
I do sometimes run screen -R before doing a long dnf operation on a remote host, because I know I can just detach the session, log out, even reboot my local machine, and then just come back later and reattach. For “special occasions”, that’s great. But I can’t imagine running that way by default, and having to deal with the clunky history access.
To use your mouse in this mode (called copy mode) press ^b + : and enter following:
setw -g mouse on
You can put this command in your ~/.tmux.conf if You want so it loads every time You run tmux.
I like also like to use mosh (https://mosh.org/) which handles intermittent connectivity issues nicely. But it doesn’t have scrollback. This is the complete solution:
You know, that’s actually not bad! It’s certainly a lot better than screen’s crappy copy mode.
It’s still weird in some ways, though. Like, for instance, I don’t get why mouse-selecting text doesn’t copy it to the clipboard. (Either of them!) And it’s cool that mouse scrolling works, but a bummer that Shift+PgUp doesn’t enter the same mode. (Though, once I start scrolling, I see that I can use PgUp / PgDnwithoutShift to move around, so that’s something.)
Maybe it’s just a matter of needing other options set.
I don’t know if it’s good enough to convince me to run that way all the time, but it’d certainly make me a lot less reluctant about bouncing into tmux before a long operation. Thanks!
Yes, the lack of highlight clipboard copying annoys me too. The way the highlight disappears immediately also prevents copying with Ctrl+Shift+C. If you find a solution please post!
I don’t think it’s an issue as in a bug, but rather the difference of how tmux does copying. The use of tmux’s copy buffer, and the challenges of entering “copy mode”, getting text copied into the normal clipboard, extra challenges of how to do this from a remote session, etc.
If someone wants to make a how-to post, that could be nice. But so far it doesn’t seem like the usual copy/paste approaches work with tmux.
That sounds strangely similar, but it’s not about tmux. Affecting the entire system… really weird issue.
(scroll to the bottom to skip the explanation and see how to copy/paste to/from the desktop clipboard.)
The Explanation
Tmux is agnostic to the window system/terminal emulator used. It simply runs in text mode using the $TERM environment variable to look up the terminal capabilities (using terminfo(5)) and then just interacts with the (pseudo-)TTY.
The mouse mode is implemented by requesting the TTY to translate mouse clicks and movements to various escape sequences and feed them to the tmux program (whether this is possible or not depends on the terminfo(5) information for the terminal emulator). Tmux will read and interpret these “mouse escape sequences”, and do the highlighting and copying of the selected text. Since it is oblivious to any GUI or windowing system (see above), it will not automatically copy the text to any other clipboard than its own internal one.
The Solution
However, it is possible to tell tmux to copy the text to the clipboard, by using some configuration magic and a CLI tool like xsel (don’t use xclip, it seems to have issues).
# TMUX configuration for copying selection buffer to the (X11) clipboard.
# Copy mouse selection tmux buffer AND to (X11) clipboard
bind-key -Tcopy-mode-vi MouseDragEnd1Pane send -X copy-pipe-and-cancel "xsel -i --clipboard"
# Copy tmux buffer to the (X11) clipboard.
bind-key C-c run "tmux save-buffer - | xsel -i --clipboard"
# Copy (X11) clipboard to tmux buffer and paste in current pane.
bind-key C-v run "xsel -o --clipboard 2>/dev/null | tmux load-buffer - && tmux paste-buffer"
# Only in tmux 1.8 and higher. Copy selection will set (X11) clipboard as well.
bind-key -Tcopy-mode-vi Enter send -X copy-pipe-and-cancel "xsel -i --clipboard"
The above text was copied selected in a tmux window and pasted here with Ctrl+V.
I presume that configuration goes into ~/.tmux.conf?
Even after installing xclip, I still can’t copy from a tmux screen; the highlighted text immediately gets de-selected as soon as the mouse button is released.
Tmux always deselects the text as soon as you release the mouse button, but it will have copied the text to its internal buffer and, if you have set up the config to use xclip, it will have also been copied to you GNOME/X11 clipboard; you can try by hitting Ctrl+V in a gedit or Libreoffice Writer document.
If you don’t like the behaviour of tmux’s “selecting text = copying it”, you can always go into manual copy mode (prefix [). That allows you to navigate using the keyboard, hit Space to start selecting text, and hit Enter to copy text to the buffer/clipboard.
Oh, I quite like highlight-to-copy. I also like middle-click-to-paste.
It’s mostly working for me, but I might be missing something: after copying something locally, I can’t copy from tmux anymore. Pasting to tmux still works.
I installed xclip on server and client, and have the same .tmux.conf on both. I also tried using tmux just locally.
tmux.conf
set -g mouse on
# TMUX configuration for copying selection buffer to the (X11) clipboard.
# Copy mouse selection to tmux buffer AND to the (X11) clipboard
bind-key -Tcopy-mode-vi MouseDragEnd1Pane send -X copy-pipe-and-cancel "xclip -in -r -selection clipboard"
# Copy tmux buffer to (X11) clipboard.
bind-key C-c run "tmux save-buffer - | xclip -in -r -selection clipboard"
# Copy GPaste buffer to tmux buffer and paste in current pane.
bind-key C-v run "xclip -out -selection clipboard 2>/dev/null | tmux load-buffer - && tmux paste-buffer"
# Only in tmux 1.8 and higher. Copy selection will set (X11) clipboard as well.
bind-key -Tcopy-mode-vi Enter send -X copy-pipe-and-cancel "xclip -in -r -selection clipboard"
Mmmh, interesting. Is this a tmux session running remotely (i.e. over ssh)?
I just noticed something. My local (Fedora) system has a version of xclip that recognises the -r flag. The host that I ssh into and test a tmux session on has an xclip that does not recognise that flag. You might want to remove the -r flag to xclip and see what happens.
Yeah, I just noticed that it’s also flaky on my side. Not sure if it’s a tmux issue or an xclip issue. Experiments with a wrapper script seem to suggest the former. At some point it just doesn’t execute the command(s) anymore.
In my case, the “prefixCtrl-C” command was making tmux unresponsive, until xclip was killed. In this case, it seems xclip didn’t notice that tmux was done giving input, and it just hung around.
I have just change my config to use xsel which seems more stable (also edited my answer above to use xsel instead of xclip).
This is what I have in my ~/.byobu/.tmux.conf for copy-pasting from tmux:
bind b run-shell "tmux show-buffer | parcellite > /dev/null && tmux show-buffer | xsel -i" \; display-message "Copied tmux buffer to system clipboard"
I use parcellite to manage the buffers. That way, I can go back and paste something I had copied hours ago.
I do remember thinking that I should move to xclip from xsel sometime, but I’m not sure why that was. This suggests xclip is slightly more featured, for example:
Yeah, I read the same page
It’s worth checking out comment #17 , though:
Nevertheless, it is neater to use xsel instead of xclip, because xclip does not close STDOUT after it has read from tmux’s buffer.
If you do decide to switch to xclip (where the only added feature is reading from/writing to files), be sure to redirect STDOUT to /dev/null when piping to xclip.
Did… did I get co-opted by some sort of stealthy discussion spam effort? I just noticed that the comment by robertic95 (…Windows 95?) is just a copy-paste of my text from an earlier comment, with that offsite link clumsily inserted.
That’s just weird, though I suppose not surprising since these days it’s basically impossible to set up any sort of discussion or forum server without the spambots descending and bringing along their plague of commercial-link insertion bullcrap.
(That being said, I don’t really understand what that site would get out of spamming, since I incognito’d it and it appears to be a pretty legitimate, face-value download site for Kodi, which is free software. No scammy pay-download links or anything like that, as far as I can see. And it doesn’t appear to contain advertising that would justify attempting to drive up the page views. I can’t figure out their angle here.)
