Practical Tmux | Hacker News Reader

Practical Tmux

mutelight.org

169 pointsweitzj94 comments

I feel like I'm the only one taking crazy pills whenever this topic comes up.

Granted, tmux has a better configuration language.

However the whole session/window/pane/instance model is bizarre, as evidenced by the secition "Multiple Clients Sharing One Session" under "common problems" in the linked article.

On top of that, the below are all given as points in favor of tmux, but they're either arguably better in screen or else a wash:

> Better redraw model

This is one of the (many) things that drove me back to screen. The two times I tried tmux, it had exactly this kind of issue where it would fail to redraw the screen correctly after SIGWINCH.

> screen contents persisted through full-screen programs

doesn't this depend on whether the program calls curses endwin() function ? why does tmux/screen need to know about this ?

> not possible to remove the visual bell from Screen completely

doesn't this work?

    vbell off
    bell_msg ""

though I'm not sure why you would want to do such a thing.

> automatic window renaming

last I checked this used a huge amount of cpu. is that no longer the case ? in any case, I name my windows according to what i'm doing in that window, since "bash" or "screen" (I use nested screen sessions) or "emacs" is not a useful window title.

> vertical splits

newish screen does this. I don't see the use. I figure I either have a roughly 80-column screen (default linux virtual terminals) or it's wide enough to have multiple 80-column windows (laptop or desktop running X). If I have enough horizontal space, I'm using a sensible window manager that is better-suited to real estate management.

Also how does tmux handle copy/paste with vertical splits ?

> vi key bindings in copy mode

is this supposed to be a win for tmux over screen ? both basic emacs and vi movement works out of the box in screen.

I'm with you. I tried tmux but didn't find any benefit and several serious drawbacks.

Many of the purported benefits - better configuration language, more maintainable code - don't matter to me:

- Screen is done and isn't going to change. Debian has had the vertical splits patch for so long I was surprised it was a patch.

- My configuration of screen is not going to change. It's five lines that I copied and pasted 10 years ago. There's just not that much that needs to be configured.

The "Multiple Clients Sharing One Session" thing is important to me and screen gets it right by default. It's useful to have a few fixed xterms on my screen and a bunch of multiplexed terminals in screen. I use one screen session per task.

I think "screen contents persisted through full-screen programs" is screen's "altscreen on" setting. Or at least that's my note from the person whose screenrc I stole.

> Also how does tmux handle copy/paste with vertical splits ?

It doesn't. If I want to copy some text and it's in a vertical split, well... shit. Time to break out the tmux manual and see if I can figure out how to move this pane above the other one. You know what, screw it. I'll just open a new window entirely, and re-run the test there so I can copy the output.

That's how tmux handles copy/paste with vertical splits.

Huh copy/paste works fine with vertical splits. Just setup tmux to sync your tmux clipboard with your regular x (or osx if you're into that kind of thing) clipboard.

You mean selecting text with a mouse on a vertical split? If so get tmux upgraded to 1.8+ then prefix-z and you can temporarily zoom the window to full screen.

Your information on tmux is highly out of date.

Also prefix-alt-2 will move to horizontal layout of panes.

Yes, the zoom feature (resize-pane -Z) is a game changer for tmux-to-system-clipboard workflows. Before that I would do the block select with my mouse and then weed out all the extra whitespace as needed later.

Woah. Just tried prefix-alt-[n], totally awesome.

Thanks!

Both screen and tmux support a feature you'll really love. Upon hitting ctrl+a/b [, both enter a "copy mode". This allows you to both scroll through the history, and to copy text from a specific pane.

Select the pane. C-b z. Copy. C-b z.

I may have misunderstood what you meant, but copy and paste in tmux works in vertical panes just the same as horizontal panes: http://d.pr/i/93p2/wNHyqVFr (copied from the right shell into vim in the left).

I think he's asking what happens if you have two panes side-by-side and try to select text in one to copy. Does it also select text from the other one?

If you use a mouse yeah, but as noted by others, with tmux 1.8+ just prefix-z and you can temporarily zoom that one pane. So there really isn't much reason to complain about this particularly.

Not necessarily. At least in Gnome-terminal, Ctrl-Alt-(mouse drag) is a block select that works just fine for copy-paste out of a vertical split.

Or do the rotation thing. Or do the copy-mode thing. More than one way to skin this cat; just depends on which workflow you wish to adopt.

This is much more awkward than just selecting it with the mouse. That's a reason to complain.

Well, this is not really the dilemma though. If you don't have vertical splits you don't have this problem, but you also don't have vertical splits. If you have vertical splits you'll solve this problem somehow.

idk what everyone else here is talking about, but I can copy with vertical panes with my mouse just fine http://i.imgur.com/lWxygYn.png

They're talking about using the host terminal's text-selection mode and the system clipboard, rather than tmux's built-in text-selection mode, which does.

I too generally use tmux's built-in text-selection and clipboard when I'm copying from pane to pane, because it's more convenient.

The thing is you can synchronize tmux selection with your clipboard, there isn't really a need for tmux to "support" your terminal's view of tmux running within.

The answer is, it depends. If you copy it with the mouse, you will be copying both sides. If you copy it with your tmux keyboard copy bindings, it will copy just the one side. I don't know the default bindings because I made mine prefix-esc to get to copy mode, vi keys, v to select, y to yank.

Like others have said, you don't use the mouse to drag & drop and copy. You use your keyboard, the way you would do it in your editor.

C-b M-2 to rotate the panes into a horizontal split.

C-b M-1 to rotate the panes back into a vertical split.

Every 4-6 months, after reading some articles about tmux, I get the urge to try it again. And I always come back to screen for many of the same reasons (and the fact that it's not on a lot of systems by default).

The session/window/pane/instance thing is definitely confusing and not well explained. I think it's even worse if you already have a lot of screen experience.

From my experience screen isn't on a lot of systems either. Usually the admins that I work with are willing to install both/either at request.

screen has the equivalent to sessions as well `screen -ls` will show them whereas `tmux list-sessions` will show the tmux ones. A window is composed of panes (analogy from physical windows, pane of glass). An instance is one user on a session.

Very much depending on what sort of installation (not the distro itself) you've got. Most of Minimal installation doesn't come with screen nor tmux by default.

> From my experience screen isn't on a lot of systems either.

Can you name one distro that doesn't include it by default? In my experience you can rely on just about every system having a core set of utilities: bash, vim, screen, ssh etc.

I'd cross both vim and screen off that list. I know Debian doesn't come with vim installed by default, and uses nano as it's editor. Sure it's trivial to install, and many admins install it the first thing they do, but it's not there by default.

vi is present in Debian by default (though not the default $EDITOR)

Debian Wheezy (and all Debians I've ever worked on prior). Not installed with a bare-bones server install.

I swear I've had to install it before on Ubuntu. This would have been awhile ago though.

It's not on Ubuntu, and IIRC not on CentOS.

I agree with you that if you have to work with multiple systems where you do not have control over installing packages, you might be better off to use pre-installed screen and vi with default configs so you can get right to work.

But if you have your own workstation and do most of the work with this workstation, tmux + customized configs might be a viable option. It just depends how good your muscle memory will keep up. :)

>> screen contents persisted through full-screen programs

> doesn't this depend on whether the program calls curses endwin() function ? why does tmux/screen need to know about this ?

I just tested out of curiosity. Running vim and exiting in tmux reverts to the previous screen contents, like in raw urxvt; in screen, the previous screen contents are lost. I do not know why.

According to this page it is related to the smcup & rmcup capability: http://chenyufei.info/blog/2011-12-15/prevent-vim-less-clear...

This is a weird feature called a "secondary screen", which means that the terminal secretly has a second buffer to draw ncurses programs on. The OP probably had this disabled in screen, so it didn't work in their terminal.

By [1] To turn it on add 'altscreen on' to ~/.screenrc

[1] https://wiki.archlinux.org/index.php/GNU_Screen

And I just tested it, too, and my terminal contents were restored. As they were with nano and emacs.

> Also how does tmux handle copy/paste with vertical splits?

This drove me nuts until I found block select. (Option-Command drag in OSX). That pretty much eliminated that problem for me.

Also prefix+z maximizes/restores a pane.

screen contents persisted through full-screen programs

The setting in ~/.screenrc that the article is missing is called "altscreen on".

If you use tmux a lot, I can't recommend tmuxp enough. https://github.com/tony/tmuxp

That looks wonderful! Being able to place the config files in project folders is a great idea. It always annoyed me when I forgot to backup the magic config folder in tmuxinator when moving machines.

Also tmuxp allows you to save the settings from a running session into a config file. That's gold.

Any comments on how it differs from tmuxinator ?

Mostly, see my response to mnem.

Also, tmuxp is python instead of ruby, and it gives you an API to interact from your python code with tmux.

I started using tmux recently, and have two life-changing tweaks to share if you're a vim user:

a) A single keyboard shortcut to navigate between both panes and vim windows in a single tmux workspace: http://www.reddit.com/r/vim/comments/22ixkq/navigate_around_...

b) Send a region from vim to a tmux/screen window: https://github.com/jpalardy/vim-slime

The combination of these gives me a nice environment for lisp hacking without needing to switch to emacs.

> a) A single keyboard shortcut to navigate between both panes and vim windows in a single tmux workspace:

Oh man you got my hopes up. This would be lifechanging if my tmux session was running on the same machine that vim was running. "#{pane_current_command}" is almost always ssh for me.

Run tmux on remote machines too. Assign different prefix keys for local and remote sessions. Has been working well for me.

> a) A single keyboard shortcut to navigate between both panes and vim windows in a single tmux workspace ...

I really wish I could get this for tmux + i3wm. I haven't really looked for a way to achieve it yet, though.

Looks like we're using the same setup.

I'm using ctrl+hjkl to navigate tmux and vim panes, and winkey+hjkl to navigate i3wm windows.

This long-time vim user thanks you.

In one of the recent releases tmux switched from starting new panes in $PWD to $HOME. I am sure they had their reasons but the new behavior is terrible for me. To get the old behavior back (AKA new pane in current working directory) add the following to ~/.tmux.conf

  bind c neww -c '#{pane_current_path}'

You can also do it for window-splits:

  unbind '%'
  bind '_' split-window -c "#{pane_current_path}"
  bind '"' split-window -h -c "#{pane_current_path}“

Here, I am using <C-B>“ or <C-B>_ for a vertical and horizontal splits.

thats terrible. starting in $PWD is the first thing I encountered that I loved about tmux as a multiplexer vs iterm

You can do that in iTerm too. Preferences -> Profiles -> General -> Working Directory -> Reuse previous session's directory

Yeah, I didn't know how much I needed starting at $PWD until I encountered tmux doing it that way.

Are you sure its $HOME? I think it's just the dir you load your session in. I just opened a new tmux session in ~/Dropbox and all new panes open in ~/Dropbox. So do my windows.

I've been using tmux for a while now, and it's a great tool. I hardly open any new terminal windows now.

If anyone is interested in the settings I've accumulated over the months, here is my config file: https://github.com/ludwig/dotfiles/blob/master/tmux.conf

Isn't ctrl-a the shortcut for beginning of line? i prefer ctrl-x

I remap Control-A that way also -- it's a holdover from my 'screen' days.

Also some interesting config files from square: https://github.com/square/maximum-awesome https://news.ycombinator.com/item?id=6306644

Cool setup, though I personally hate using Ctrl-A for the prefix. I am too engrained to that being beginning of line. I use Ctrl-O since that doesn't seem to interfere with anything major.

I started using tmux about 2 years ago and don't know how I lived without it.

Same here, but I use Ctrl-j. I never understood why I see everyone using Ctrl-a and Ctrl-b. Those are two very important navigations in my opinion.

not that important if you have:

    set -o vi

in your bashrc.

Better yet, use `set editing-mode vi' in your .inputrc so that bash and other readline enabled utilities default to vi-style bindings.

I am still used to <C-B> as a prefix. For splitting windows I am using <C-B>“ for the vertical split, and <C-B>_ for the horizontal split.

The lines indicate the splitting direction, and I do not have to move my fingers around that much to reach, e.g <C-B>%

I've always found the backtick (`) to be the most convenient for me. I can hit it easily with my left hand ring finger and I don't have to type backticks too much as I typically use $(command) for command substitution.

Agreed. I fell in love with Tmux from the moment I realized it used <C-b> as the prefix. Still accessible with just my left hand (especially since I map Caps Lock to Ctrl), but doesn't block a commonly-used chord.

Ctrl-a a gets you to beginning of line. My problem is that I'm so used to that combo that on the rare occasions that I'm not in a screen/tmux session, I keep putting "a"s at the start of the line.

Note that maximum-awesome is for/by the vim crowd -- who could not care less about Ctrl-A being move-beginning-of-line but do want continuity with screen's prefix-key.

Can someone explain the benefits of using tmux or screen or something similar over opening multiple terminals in a tiling WM?

The two arguments I could see are resource usage (not an issue on modern machines) or detach/attach (which is a huge benefit when working remotely, but I don't see any gain locally). But other than those, I don't see any benefits to having a second tiling system sitting on top of my current tiling system.

(For reference, I use i3.)

Xmonad user here. Sessions are wonderful. I can run one just for xmonad as a job (I like to hack that config quite often ). Another just for my VPN script (which puts out I/O stats every few minutes).

And per project, I'll have a few. Say I have one where I have one shell for compilation, one for version control, and two for testing. Give each one a prefix for the project, and I've got all that separated out. E.g.: Two projects: foo and bar: foo-compile, foo-git, foo-test-a, foo-test-b, bar-compile, bar-git, etc..

Now, I have clean shell histories (and scroll buffers) for each. I can ssh into each one as I want, and reuse my terminal windows. This latter bit helps keep my already-complex-enough window setup manageable.

1. You might not have a tiling window manager in the first place (there are no decent ones on OS X that don't require manual operation to my memory).

2. You work on a remote machine and prefer to have your window layout remembered there, so it can instantly be restored no matter what computer you're physically working on, whether or not it happens to have or even support your favorite tiling window manager.

3. It's simply easier for me to do everything within one terminal window full-screened on a 27 inch monitor. It's less context switching.

I completely agree with 1 and 2 - my question was related to a local machine with a tiling WM.

For 3, can you elaborate? How is it less context switching? You're doing the same set of operations in both settings - switching, moving and resizing terminal windows (whether real or virtual).

For those who find tmux a bit arcane and screen a bit too primitive, I've found dvtm+dtach to be an excellent terminal multiplexer and session manager.

s/dtach/abduco/

Abduco is a dtach replacement by dvtm's author. From http://www.brain-dump.org/projects/abduco/ :

"abduco is in many ways very similar to dtach but is actively maintained, contains no legacy code, provides a few additional features, has a cleaner, more robust implementation and is licensed under a BSD style license"

Thanks, I had not seen abduco. I'll have to try it out.

I love the design but never made the switch, any tutorial to suggest ?

The best source for the default commands is the dvtm man page.

My one gripe about tmux is that when doing things like `git commit` where it will open my editor (ST2), after I close the editor, tmux never realizes the file has been closed, so it just hangs there. If I do the exact same command outside of tmux, it doesn't.

Two issues in tmux not fixed or this way by design are missing flow control and that you have to explicitly bind shortcuts which work in gnu screen automatically without pressing Ctrl twice. Other than that it's good.

"without pressing Ctrl twice" should be "without pressing the binding while not holding down Ctrl". Quickly pressing C-b c in tmux while still holding down Ctrl doesn't work without an explicit binding and it does in gnu screen.

Here's another tmux guide with a few other tricks http://blog.soarez.com/post/57348732818/tmux

So does anyone know if there's a setting to make searching in copymode case insensitive? This is the biggest reasing I can't switch to tmux...

It is insensitive. Unless you enter an uppercase character, in which case that search turns case sensitive. Just like in every other program...

Practical Tmux? He changes the default prefix, but he only tells you after the first example.

One annoyance is that both tmux and screen have problems with truncating long lines in less.

This is very strange, could you describe he problem more? Also, does the contents of an ncurses app (vim, less, emacs) stay after you close the program?

When I use less in a tmux or screen session to view /var/log/syslog et al, when I type -S to chop long lines it continues to wrap the line instead of chop it.

No the screen is cleared after quitting.

I have TERM set to xterm-256colors FWIW.

What does "tput cols" say in and out screen/tmux? It's possible less doesn't know the proper width of the terminal.

80 cols, which is correct. Less seems to be fine when not in a tmux session.

https://asciinema.org/a/9601

Odd, I'm doing that daily at work without any issue. (tmux 1.8.x, putty, screen-256colors I believe)

I've switched to 'most' instead. You can use < and > to scroll left and right in the document.

Works like a charm! Thanks!

I play tictactmux at pomodoro intervals with clock-mode panes representing state. Roll d9 at turn for next move.

byobu

Reply on news.ycombinator.com