"What is a terminal multiplexer? It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal. And do a lot more. See the manual."
That's awesome. So many times someone posts on HN "CaffBook.ly.errr 0.98 now released" and I have no idea what it is or why I would want it.
For me, tmux has saner options and more mnemonic default keyboard shortcuts, that do not interfere with default bash shortcuts (Ctrl-A is goto-home-of-line in bash/emacs, but it is hijacked by screen by default as its escape sequence; tmux uses Ctrl-B for the same by default, which in the emacs bindings means go-back-a-character, and I do not use much, and is less likely to hit by accident).
Some of it is arguable, but for me one of the greatest benefits is how tmux will auto-resize to the smallest terminal connected, making it useful for screen sharing or when connecting to an existing session from a mobile device.
If you like tmux, also check out teamocil (https://github.com/remiprev/teamocil) to really enhance your use. It enables you to define tmux sessions via YAML, which is great for programmatically setting up a complex dev session. Mine, for example, fires up six panes in my preferred layout, and starts up a particular part of our project in each pane.
I used to use tmuxinator, but it's pretty much abandoned. There are pull requests that are over a year old. On the other hand, I submitted a pull request to teamocil and it was merged the same day.
I'll actually help maintain tmuxinator now. :) The project is really awesome but the author doesn't have enough time for it, so he added me to the project a few days ago. I'll go through the pull requests soon.
If you don't like the YAML format of teamocil or tmuxinator and just want to write shell scripts to do the same thing, check out tmuxstart: https://github.com/treyhunner/tmuxstart
I made it shortly after switching to tmux last year. I hope this kind of functionality will eventually be built-in to tmux.
I agree. It takes surprisingly few lines of code to make a nice wrapper with some shortcut aliases/functions to simplify the scripts. My whole tmux workflow is managed by about 30 lines of code to bootstrap by tmux session management: https://github.com/treyhunner/tmuxstart/blob/master/tmuxstar...
You could achieve the same thing with shell scripts, but one of teamocil’s advantages is that it gives you the simplicity of YAML to build complex layouts.
These days it's very easy to use a simple api without knowing about the dragons lurking beneath the surface. Flip side of our "reusable components" holy grail.
It's definitely a well-done, and I'll be pointing new users of tmux at it. I would have been all over it if I would have seen it the first time I dove into tmux's man page way back when.
If I get a chance, I'll give a go at converting the scripts for some of the layouts I use all the time, and see if it sticks.
I use vim-slime[1] to send strings to other panes in tmux. I never type anything directly into a REPL. I just send my code from Vim to it. It's amazing with lisp or python. (A little less amazing with php, as the php repl IS AWEFUL)
I realise you can rebind them, but both screen and tmux do themselves a disservice by choosing binding keys which overlap with prominent keys in emacs and for users who use emacs mode in their shell.
First impressions count.
If you want to configure tmux to use just a backtick as the escape, create ~/.tmux.conf
unbind C-b
set -g prefix `
bind-key ` send-prefix
When you need to type a backtick just press it twice.
For screen, I used to do this:
escape ``
.. in ~/.screenrc, but I've just tried it and it seems that there's now no easy way to type a backtick when you need one.
Query: in screen I can switch between two buffers by doing ctrl+a, ctrl+a. This doesn't work in tmux. How do I configure this to work in tmux?
One reason to run Emacs in tmux is if you work on remote machines over, e.g. ssh. Emacs in tmux (or screen) lets you detach, log out then log back in and re-attach to the remote session with Emacs still running. That's amazingly handy.
You still need a remote shell open if you want to run make, use SCM plugins, etc, so I've never found tramp that useful. If there's a clever solution for that I'd love to hear it.
eshell interfaces pretty well with tramp (well, not over FTP obviously, but ssh) so if you're editing a file over tramp and start eshell, it'll be in the directory of the file on the remote host. you can also use tramp-y paths in eshell:
I realize I'm a bit late to reply, but thanks for the tip. The biggest problem I had was with p4 mode (we use perforce at work) and rope-mode - I didn't really feel like hacking those to get it to work with tramp. And I can keep everything open across network disconnects with screen or tmux...
Well - it's my tool of choice for editing Makefiles. :) But that's all I use it for. My vim setup automatically hammers tabs to spaces, and make doesn't like that.
Shell users who use emacs mode (most ppl) may be annoyed by ctrl+a missing.
I stole this (possibly from Steve Yegge or another source) long ago to somewhat automate the process of renaming terminal buffers:
(global-set-key (kbd "<f2>") 'visit-ansi-term)
;; Terminal awesomeness
(require 'term)
(defun visit-ansi-term ()
"If the current buffer is:
1) a running ansi-term named *ansi-term*, rename it.
2) a stopped ansi-term, kill it and create a new one.
3) a non ansi-term, go to an already running ansi-term
or start a new one while killing a defunt one"
(interactive)
(let ((is-term (string= "term-mode" major-mode))
(is-running (term-check-proc (buffer-name)))
(term-cmd "/usr/local/bin/zsh")
(anon-term (get-buffer "*ansi-term*")))
(if is-term
(if is-running
(if (string= "*ansi-term*" (buffer-name))
(call-interactively 'rename-buffer)
(if anon-term
(switch-to-buffer "*ansi-term*")
(ansi-term term-cmd)))
(kill-buffer (buffer-name))
(ansi-term term-cmd))
(if anon-term
(if (term-check-proc "*ansi-term*")
(switch-to-buffer "*ansi-term*")
(kill-buffer "*ansi-term*")
(ansi-term term-cmd))
(ansi-term term-cmd)))))
Hey, I found that code hard to follow, with the if-then-elses nested 4 deep. A refactor, pretty much untested since I don't use ansi-term:
(defun visit-ansi-term ()
"If the current buffer is:
1) a running ansi-term named *ansi-term*, rename it.
2) a stopped ansi-term, kill it and create a new one.
3) a non ansi-term, go to an already running ansi-term
or start a new one while killing a defunct one."
(interactive)
(let ((is-term (string= "term-mode" major-mode))
(is-ansi-term (string= "*ansi-term*" (buffer-name)))
(is-running (term-check-proc (buffer-name)))
(anon-term (get-buffer "*ansi-term*")))
(cond
((and is-term is-running is-ansi-term)
(call-interactively 'rename-buffer))
((and anon-term (if is-term
(and is-running (not is-ansi-term))
(term-check-proc "*ansi-term*")))
(switch-to-buffer "*ansi-term*"))
(t
(cond ((and is-term (not is-running))
(kill-buffer (buffer-name)))
((and anon-term (not (term-check-proc "*ansi-term*")))
(kill-buffer "*ansi-term*")))
(ansi-term "/usr/local/bin/zsh")))))
I've never been able to get it to deal well with vast amounts of output well. Constant overwriting issues etc. Definitely prefer to use tmux + emacs considering the huge amount of stuff i end up throwing at my term.
This isn't very useful if what you want to run in your terminal buffer needs to constantly update its screen while you're working in a different buffer (e.g. irc, tailing log files, etc)
Umm.. why is it not useful? Emacs will allow multiple buffers to update at once, and you can work in a third while watching them... That's kind of the idea.
Per your query: ctrl+a ctrl+a is how I switch between two windows (tmux calls them windows, they're basically tabs). If you want to switch between two panes (divisions inside a window, the equivalent of splitting the screen in a regular editor or visible buffers in vim/emacs), use ctrl-a o. I also have these bindings in my tmux conf for moving between panes painlessly:
# use hjkl for moving
bind h select-pane -L
bind j select-pane -D
bind k select-pane -U
bind l select-pane -R
On most keyboards, you can enter it with control-space, which is very easy to type and rarely used for other purposes (though emacs uses for `set-mark-command`).
Control-] can also be a good choice (at least for US-style keyboards that don't require shift for the square brackets).
I think the idea is to be able to pound on whatever the defined escape key is to be able to toggle buffers, not that's he unable to find a command to switch to the next window.
That's not quite what I'm after. I guess it's hard for non-screen people to know what I'm talking about from my vague description above :)
Here's a scenario to show what I mean: you're in buffer 5. You switch to buffer 2. Now if you do ctrl+a, ctrl+a, you leap back to buffer 5. And if you do it again, you go back to buffer 2. This is great when you're editing code in one session and running it in the other.
Is there a way to set it up to do this if you hit (escape-key) (current buffer index)? That's the way weechat works, and I keep expecting it to work in tmux as well :/
* Resizing panes will now reflow the text inside them.
Finally! I did not expect this feature, I thought the author was opposed to it. It is the one thing I have missed from screen (and part of the reason why I originally started using screen, since xterm does not reflow on resize either).
I want to like tmux, I really do, but my main gripes are scrolling in panes with the scroll wheel and selecting / copy/pasting text. iTerm (osx) or Terminator (linux) handle that much better, although I admit they can't really be compared technology-wise.
Alternatively, I never figured out how to select / copy text just as fast in tmux / vim / etc as with the mouse.
> * Control mode, which is a way for a client to send tmux commands.
> Currently more useful to users of iterm2.
With this, if you connect to tmux via iTerm2, you can get it to pop up a window with tabs for each shell in the tmux session. History via the mouse wheel is native, changing tabs is native, new tab is native. Essentially you don't need to know any of the tmux commands at all unless you connect from a terminal program that doesn't know the protocol.
* Session choosing fixed to work with unattached sessions.
* New window options window-status-last-{attr,bg,fg} to denote the last
window which was active.
* Scrolling in copy-mode now scrolls the region without moving the mouse
cursor.
* run-shell learnt '-t' to specify the pane to use when displaying output.
* Support for middle-click pasting.
* choose-tree learns '-u' to start uncollapsed.
* select-window learnt '-T' to toggle to the last window if it's already
current.
* New session option 'assume-paste-time' for pasting text versus key-binding
actions.
* choose-* commands now work outside of an attached client.
* Aliases are now shown for list-commands command.
* Status learns about formats.
* Free-form options can be set with set-option if prepended with an '@'
sign.
* capture-pane learnt '-p' to send to stdout, and '-e' for capturing escape
sequences, and '-a' to capture the alternate screen, and '-P' to dump
pending output.
* Many new formats added (client_session, client_last_session, etc.)
* Control mode, which is a way for a client to send tmux commands.
Currently more useful to users of iterm2.
* resize-pane learnt '-x' and '-y' for absolute pane sizing.
* Config file loading now reports errors from all files which are loaded via
the 'source-file' command.
* 'copy-pipe' mode command to copy selection and pipe the selection to a
command.
* Panes can now emit focus notifications for certain applications
which use those.
* run-shell and if-shell now accept formats.
* resize-pane learnt '-Z' for zooming a pane temporarily.
* new-session learnt '-A' to make it behave like attach-session.
* set-option learnt '-o' to prevent setting an option which is already set.
* capture-pane and show-options learns '-q' to silence errors.
* New command 'wait-for' which blocks a client until woken up again.
* Resizing panes will now reflow the text inside them.
* Lots and lots of bug fixes, fixing memory-leaks, etc.
You're going to open a big can of worms with that one ;). Tmux has quite a few more features than Screen, with Screen having a few features that are useful in edge cases[1]. It's hard to argue with tmux having bindings for vi/Emacs, as well.
If you're on a mac and use iTerm2, using tmux is somewhat of a no-brainer, thanks to the integration between tmux and iTerm2[2].
With reflowing text added to tmux, and giving that "Lots and lots of bug fixes, fixing memory-leaks, etc." the benefit of the doubt, then I would say that unless you have a specific use case of screen (and if you do, you know it) then you should be using tmux.
After mastering screen, I switched to tmux. It's a lot easier to configure. It's also a lot nicer to split panes etc...
Definitely recommend the switch. You might be dreading it, but two days into tmux you won't regret it. It took many weeks trying to convince myself screen is better until I actually tried tmux out.
The only two pains that come with it are a) having to type `` to get a single `, and b) pasting anything containing a backtick behaves as if you'd typed it out.
Author here. I know it's better for you to get the book cheaper, but PragProg gives authors 50% royalty on the sale of the book. If you buy it from pragprog, I get more in my pocket than if you buy from Amazon.
Either way, thanks for reading. I hope it's enjoyable. Some minor updates are coming to the book too.
AFAIK there are tmux 'windows' which are like tabs and 'panes' which are vertical and horizontal splits in 1 tmux window
but assuming you mean 'panes', it seems you can:
Ctrl-b o
to move around the current window's panes clockwise. Although I prefer inputing a given direction like the other replier suggested with arrow keys.
For me moving between windows and panes is something that I do a lot. So much so that I removed the need to use the 'tmux prefix' to do so. In my ~/.tmux.conf I have for window and pane switching:
# set pane switching with <alt>{U, E, N, I} for up, down, left, right and respectively without needing prefix
bind -n M-N select-pane -L
bind -n M-I select-pane -R
bind -n M-U select-pane -U
bind -n M-E select-pane -D
# set window switching without needing prefix
bind -n M-a select-window -t :1
bind -n M-r select-window -t :2
bind -n M-s select-window -t :3
bind -n M-t select-window -t :4
bind -n M-d select-window -t :5
bind -n M-h select-window -t :6
You can just replace the keybindings I chose like M-a (alt-a) to something that works for you. If you want to keep using a prefix (incase you are worried the keybindings will clash with other program/system bindings), remove the '-n' flag. Hope that helps.
I also did the thing to get rid of the tmux prefix for pane switching. But since I don't use the function keys, I mapped keys F1 through F9 to various tmux functions. F1 = next pane, F2 = prev pane. One less key to press. :)
It binds the function keys which makes life so much easier. F2 starts new window, F3 and F4 rotate back and forwards. It also has a pretty neat status line.
For what it's worth, here is my carefully crafted ~/.tmux.conf file. I was used to screen, so I carried most of the keybindings along when I switched to tmux.
Two things I missed from screen last I tried tmux: an equivalent of 'screen -xRR' and an orthogonality between terminals and windows so that distinct terminals connected to one session can display different windows. Especially the latter of these is integral to my workflow.
tmux status bars are customizable(no surprises there I guess) and the powerline is one of the nicer status bar arrangements - https://github.com/erikw/tmux-powerline
If you are moving from screen to tmux, it's very easy to configure tmux to behave like screen. Also, for split panes, I like vim bindings('C-a l' for left pane, 'C-a r' for right pane, 'C-a <' for resize pane...). I have bindings for copying tmux buffer to and from clipboard(needs xclip).
Don't know if I'm the only one in this boat, but I often feel pretty conflicted about upgrading to a newer version of a tool where I have had a lot of configuration and shortcuts defined for ages. If any of them break, you'll have to go back and dig through the arcane tmux config file, figure out what changed.
For the lulz I use neercs. It's the same as screen and tmux, except you get thumbnails of your panes in some kind of taskbar; and most importantly, you can switch between panes with a cube ascii animation, compiz style.
the new choose-tree commmand is superb, for anyone who regularly uses tmux and already understands how great it is, you should consider upgrading for this alone..
with several sessions running on most of my machines, i frequently found myself `detaching` and `reattaching` to a different session... as the `choose-session` command gives you a full list of all the windows, which tends to obfuscate exactly what's going on, particularly if you have a bunch of sessions and windows..
however, the `choose-tree` gives you a session tree, which you can expand and easily identify... meaning that instead of sending `^a d`, followed by tmux attach sessionname you can comfortably do a `^a s` and get where you want to be (presuming you've remapped ^b to ^a)
also, you should be using the tmux buffers, `^a =`!
One thing that I really want is the ability to set different background colors for panes and windows. Sadly, it is a feature of a terminal app, not tmux. One can only imagine tmux would integrate tightly with various terminal applications to accomplish that.
Does this release have better performance than previous releases? I enjoy using tmux, but for some applications (i.e. with large amounts of text spewing to the console) it just hasn't (historically) performed as well as GNU screen.
i've switched from tmux to screen to byobu ( which is a wrapper for screen ) because of its simplicity.
screen also has very little problems, with tmux i always had time costly issues.
Anyone know if it is possible to do single combination keybindings? Currently all of the keybindings are things like 'Ctrl+W L', whereas I'd like to do things like 'Command+L'?
If you use bind-key -n C-f some-tmux-command it'll bind directly to Contrl-f. The -n means no prefix. I don't know how you'd make tmux recognize the Mac's command key though.
Yes, formally. You don't have to specify -z in GNU tar today, you can just say -x and it'll add -z or -j for you -- it figures out on the fly if the archive's been compressed and how. Very convenient.
instead of make install, consider checkinstall or fpm so that you are properly integrated into ubuntu's native package manager (dpkg). Doing so will save you headaches when you want to uninstall tmux or upgrade later.
Well the easiest way is either to wait for it to appear in the repos or wait for someone to package it and put it into a PPA. However, it doesn't have that many dependencies, so building it yourself is another not too stressful option.
I continue to be amazed by the people who install "random binaries" via PPA.
I guess I assume that if you want cutting-edge packages you'll use a cutting-edge release/distribution. If you don't, and you want something more recent then it seems to make sense to make your own packages, or install locally via gnu-stow, or similar.
"tmux is a terminal multiplexer"
"What is a terminal multiplexer? It lets you switch easily between several programs in one terminal, detach them (they keep running in the background) and reattach them to a different terminal. And do a lot more. See the manual."
That's awesome. So many times someone posts on HN "CaffBook.ly.errr 0.98 now released" and I have no idea what it is or why I would want it.