Basically a daemon session is started (if it wasn't there before) and every terminal you open automatically connects to that session.
This means that you can close every terminal, the session is still open and new terminals will use the already existing session. As long as tmux itself isn't stopped (reboot, etc.) you'll stay in the same session.
Which is cool because everything is de facto detached.
That's a pretty cool setup. These slides have been prepared for a 4mn lightning talk so I had to keep things simple and short enough!
Anyway, I really like your setup. I'm thinking these days about writing my own terminal multiplexer just for fun using node.js. I already have the VT emulation part ready so there's no that much work left to do.
Do you have any feature you don't have in tmux that you would love to see in a terminal multiplexer or is tmux just right for you?
By Thor, are image macros really necessary? It seems you can't have a technical presentation these days without some silly generic "memes" sprinkled all around, it's ridiculous.
You need something, yes. The purpose of a presentation is to be entertaining enough that your audience will not be bored to tears, and will actually still care about the subject after you're done.
Images work well, because they evoke a more emotional response. Memes are there for a different reason - they are a non-verbal way of saying "hey, we're all part of the same subculture. I'm one of you!".
Yes, presentations are to some extent an exercise in psychology, at least when they're good.
If you just want to convey info, a whitepaper/article is a better choice. Information density is much higher there.
Since this is a post about tmux, I feel obligated to tell you about teamocil (http://teamocil.com) a small utility I wrote to automatically create sessions, windows and panes in tmux with YAML files :)
Teamocil is usually the thing I show non-tmux users, that then makes them want to use tmux. Awesome utility, Remi, great job! (with apologies to Tim and Eric)
It seemed to hijack in Firefox but not Chrome (Ubuntu), but it's a little hard to tell since the site's dependency on documentup.com, which appears to be taking a shit right now, is screwing with page loads and such.
These slides are always so out of context without hearing the audio presentation, or better, seeing the video of the presenter.. when I flip through these slideshows with the mem/macros/whatever they are called, I always imagine the audience sitting there, forced smiles, maybe a cough, and then on to the next slide.
These should be refactored after the local presentation. Like how episodes of The Simpsons will cull out really topical jokes that won't be funny in a month for the sake of syndication.
tmux is cool, and wemux is a tool we use regularly to share sessions. I am an old screen guy and appreciate that there is something similar being produced, as both products get invigorated by new features and bug fixes. I believe there is even a screenrc mode for tmux so that I can keep my muscle memory - what a great feature!
The reason the Simpsons cut material is that shows in syndication have a shorter running time to permit more ads to run during them. It's more noticable than usual with the Simpsons because the joke density is higher than most sitcoms.
Screen doesn't seem to be getting much invigoration, seeing as the most recent release was in 2008, and only three version control commits have been made in the last 12 months.
Screen is, for all intents and purposes, a dead project. There's no co-invigorating going on. ALL new development is happening in tmux.
So as a user of emacs, a user of tmux, and the soon to be recipient of a dell XPS 13 which I intend to dock at home with a very big screen and use with Xmonad... Do I need tmux?
It seems to fall between the gaps between easily switching between panes and applications, which you can do with Xmonad and what you can do with buffers in emacs.
With my previous setup I used tmux to run all my deamons (web servers I was developing on, continuous coffeescript and less building etc) in one terminal, but I'm not sure there was a huge benefit vs just opening a new terminal for each process (in hte same workspace) and using Xmonad to manage the layoutt/switching. Am I missing a trick here?
I definitely agree that the multi window/pane feature of tmux can be repetitive of your window manager, especially if you use a tiled window manager.
But at the same time I keep thinking that most people do not use their window manager to manager their browser tabs (despite the existence of surf (http://surf.suckless.org/). Why? Not sure...
Tmux can be extremely useful to bootstrap a working environment rapidly. We use it to connect to our mongo replica set rapidly without having to ssh into each machine. See the comments below there are a few tools to help you do that.
Tmux is also extremely useful for pair programming: you can multiplex PTYs but you can also have multiple screens attached to the same session. It's a killer feature especially when working remotely with your team.
If one likes tmux, may I recommend having a look at 'byobu'. It's built to use either tmux or screen as a backend and provides some features that make life slightly easier than using barebones tmux or screen. However, I must warn that it is just a matter of convenience and it doesn't really add anything significant.
I have a feeling tmux would be useful to me, but it seems to be one of these things where all the documentation is useless unless you already understand it.
I understand it's a terminal multiplexer: so, on the one side, I have one or more terminals (typically pseudo; X or ssh in my case), and one or more ∗nix sessions (typically each a single process group; shells and their children like editors). In between sits tmux, with its 'sessions' and 'windows' and 'clients' and 'buffers' and 'panes'. What are these things, how are they related, and how do they correspond to ∗nix sessions and terminals?
When you type "tmux" into a terminal, that starts a client. A client is the instance of tmux that's running in your terminal emulator. tmux manages a collection of pseudoterminals, and clients display whatever is going on in that collection.
(Warning: some oversimplifications.) This collection of pty's is called a session. Each pty within it is called a window. When you start, there will be one session containing one window. You can add more windows (C-b c) and switch the one your client is currently viewing (C-b p, C-b n, etc.) Each new window will start a shell that you can use to run programs independently.
Detaching (C-b d) means disconnecting your client from the session and exiting. Attaching ("tmux attach") reconnects to the session.
Multiple sessions and multiple clients are an advanced topic. Don't worry about them yet.
Unix sessions are unrelated to tmux sessions. Technically, each pty managed by tmux has its own Unix session.
Buffers and panes are advanced topics. Buffers help with copying and pasting; panes let you split windows into multiple pty's. Don't worry about either of them yet.
First of all, "clients" are the things that TFA labels "tmux (screen)". Each of "windows" and "panes" are things you can ignore, or not, as you find them useful. Windows are like browser tabs, panes are screen-splits. I use windows, I don't (yet) use panes. Otoh, many people are in it just for the planes. YMMV. But you cannot use tmux without "clients" and "sessions".
Second of all, `man screen` does discuss the theory and how things interact. So if you have 20 or 30 minutes, you can read the man page and basically Learn All The Things.
----------
Third, you said you're interested in m:n. Maybe my tmux workflow is relevant to you.
I have, let's imagine, a need for 5 terminals. "notes", version-control, make/tests/etc, misc-bash, and vim. I make space on my desktop physical monitor for three terminals (100x60); but only one on my laptop (100x40).
I start by creating one Session that contains five Windows, and each window corresponds to one of the five ptys that I want (notes, vcs, make, bash, vim). But I can only view one of these at a time, right?
TMUXSESS=foo
tmux new -d -n notes -s "$TMUXSESS"1 # new detached session "foo1", with window "notes"
tmux neww -P -n vcs -t "$TMUXSESS"1: # new window "vcs" in existing session "foo1"
tmux neww -P -n make -t "$TMUXSESS"1:
tmux neww -P -n bash -t "$TMUXSESS"1:
tmux neww -P -n vim -t "$TMUXSESS"1:
So now I could connect three (or twenty) clients all to the same session. BUT, this isn't the solution, because they'd all the same view of what I'm doing (which is amusing at first, but useless).
But, hooray, introducing another tmux concept, "groups". "Groups" are groups of sessions, that contain the same windows, but do not have to share a view.
tmux new -d -s "$TMUXSESS"2 -t "$TMUXSESS"1 # new session "foo2" grouped with "foo1"
tmux new -d -s "$TMUXSESS"3 -t "$TMUXSESS"1
Now I open my three gnome-terminals. In the first one I do
tmux a -t "$TMUXSESS"1 # attach to "foo1"
and likewise for the second and third.
And if I feel like working from my laptop, I vpn+ssh to my desktop, and just attach another tmux client to foo1 or foo2 or foo3. This one shares a lock-stepped view with the session it's attached to, but who cares, I'm not watching the desktop. Tmux resizes every session to the minimum-sized attached client, so it's important that I detach my laptop-client when I wanna go back to my desktop. If I forget, no problem, tmux lets me do that from either keyboard (though I have to look up the syntax to do it from my desktop's keyboard).
So, 5 things to look at, 3 or 4 views into those things, arbitrary swapping each to the other. I haven't been using this very long. It's GLORIOUS. Does that help?
I've written a CLI (ruby gem: tmux-connector) that uses tmux to help you handle connections to multiple servers with ease. I use it on a daily basis to manage ec2 instances. https://github.com/ikusalic/tmux-connector
Tmux is great for working together with someone. Syme[1] uses tmux as well, and allows you to quickly program on a GitHub project with others, without setting up a server or needing to add users. I think this is relevant, as it shows the convenience of tmux.
Every slide that says "tmux (screen)" should say "tmux (client)".
This is especially true because when people who view these slides google for more information, and they google for "tmux screen", they're gonna get rants about tmux vs screen.
EDIT: also, I would suggest renaming this to "elementary uses of tmux explained". Because obviously this is like 1% of the use of tmux (but the best 1% to start with, imo!)
I sit beside a coworker who wrestles with tmux daily.
He likes it, but it also frustrates him; it crashes semi-regularly, it sometimes locks out input when one program is spamming one of the tiles, and due to it intrinsic nature you can no longer select-copy large blocks of text with the mouse if you have any vertical splitters.
The lack of block text select-copy is alone enough to keep me away.
Most of the other benefits can be gotten with screen, with better reliability and performance. I use several customized .screenrcs for various tasks, to get started up quickly every reboot. But I don't run screen in every terminal because native scrollback buffer is too valuable.
Block mode selects don't know whether to wrap lines or not; most half-decent terminals keep track of whether wrapping was due to carriage return or hitting the last column.
I do this all the time to e.g. select deleted files from a git status command so I can xclip paste the selection out through awk to xargs git rm (or rather, use some scripts which simplify the above). Similarly for rspec / cucumber test results to extract out the failures for use with $(<failures.txt) on repeated runs as I fix broken tests. I have a script that analyzes ruby stack traces, which I copy from the crashed session. All sorts of ad-hoc clickery, I rely on word wrap being detected consistently.
So.. I never really understood why we need tmux/screen beyond some vanity things like running irc clients. Most applications should have sufficient log output to a file. Editing a document, want to return to it later? Save the thing.
Not sure I understand why people would be so excited about this tool?
The traditional monster use-case for screen is making your login session independent of the terminal connection. So you can do your work from home, detach your screen session, go to work, re-attach from work, and continue where you left off. If your terminal connection dies, you can just re-attach from a new connection.
It also offers other convenient session management functions like multiplexing of multiple shells (maintaining a separate screen image and scrollback for each), cut-and-paste, etc., but the above is the big one I think.
54 comments
[ 3.0 ms ] story [ 105 ms ] threadBasically a daemon session is started (if it wasn't there before) and every terminal you open automatically connects to that session. This means that you can close every terminal, the session is still open and new terminals will use the already existing session. As long as tmux itself isn't stopped (reboot, etc.) you'll stay in the same session.
Which is cool because everything is de facto detached.
Anyway, I really like your setup. I'm thinking these days about writing my own terminal multiplexer just for fun using node.js. I already have the VT emulation part ready so there's no that much work left to do.
Do you have any feature you don't have in tmux that you would love to see in a terminal multiplexer or is tmux just right for you?
Images work well, because they evoke a more emotional response. Memes are there for a different reason - they are a non-verbal way of saying "hey, we're all part of the same subculture. I'm one of you!".
Yes, presentations are to some extent an exercise in psychology, at least when they're good.
If you just want to convey info, a whitepaper/article is a better choice. Information density is much higher there.
These should be refactored after the local presentation. Like how episodes of The Simpsons will cull out really topical jokes that won't be funny in a month for the sake of syndication.
tmux is cool, and wemux is a tool we use regularly to share sessions. I am an old screen guy and appreciate that there is something similar being produced, as both products get invigorated by new features and bug fixes. I believe there is even a screenrc mode for tmux so that I can keep my muscle memory - what a great feature!
Screen is, for all intents and purposes, a dead project. There's no co-invigorating going on. ALL new development is happening in tmux.
It seems to fall between the gaps between easily switching between panes and applications, which you can do with Xmonad and what you can do with buffers in emacs.
With my previous setup I used tmux to run all my deamons (web servers I was developing on, continuous coffeescript and less building etc) in one terminal, but I'm not sure there was a huge benefit vs just opening a new terminal for each process (in hte same workspace) and using Xmonad to manage the layoutt/switching. Am I missing a trick here?
But at the same time I keep thinking that most people do not use their window manager to manager their browser tabs (despite the existence of surf (http://surf.suckless.org/). Why? Not sure...
Tmux is also extremely useful for pair programming: you can multiplex PTYs but you can also have multiple screens attached to the same session. It's a killer feature especially when working remotely with your team.
I switched from screen after reading this awesome book: http://pragprog.com/book/bhtmux/tmux
I understand it's a terminal multiplexer: so, on the one side, I have one or more terminals (typically pseudo; X or ssh in my case), and one or more ∗nix sessions (typically each a single process group; shells and their children like editors). In between sits tmux, with its 'sessions' and 'windows' and 'clients' and 'buffers' and 'panes'. What are these things, how are they related, and how do they correspond to ∗nix sessions and terminals?
Or have I got it all wrong? http://i.imgur.com/zJGunty.png
(Warning: some oversimplifications.) This collection of pty's is called a session. Each pty within it is called a window. When you start, there will be one session containing one window. You can add more windows (C-b c) and switch the one your client is currently viewing (C-b p, C-b n, etc.) Each new window will start a shell that you can use to run programs independently.
Detaching (C-b d) means disconnecting your client from the session and exiting. Attaching ("tmux attach") reconnects to the session.
Multiple sessions and multiple clients are an advanced topic. Don't worry about them yet.
Unix sessions are unrelated to tmux sessions. Technically, each pty managed by tmux has its own Unix session.
Buffers and panes are advanced topics. Buffers help with copying and pasting; panes let you split windows into multiple pty's. Don't worry about either of them yet.
http://copperthoughts.com/p/tmux-simply-explained/
First of all, "clients" are the things that TFA labels "tmux (screen)". Each of "windows" and "panes" are things you can ignore, or not, as you find them useful. Windows are like browser tabs, panes are screen-splits. I use windows, I don't (yet) use panes. Otoh, many people are in it just for the planes. YMMV. But you cannot use tmux without "clients" and "sessions".
Second of all, `man screen` does discuss the theory and how things interact. So if you have 20 or 30 minutes, you can read the man page and basically Learn All The Things.
----------
Third, you said you're interested in m:n. Maybe my tmux workflow is relevant to you.
I have, let's imagine, a need for 5 terminals. "notes", version-control, make/tests/etc, misc-bash, and vim. I make space on my desktop physical monitor for three terminals (100x60); but only one on my laptop (100x40).
I start by creating one Session that contains five Windows, and each window corresponds to one of the five ptys that I want (notes, vcs, make, bash, vim). But I can only view one of these at a time, right?
So now I could connect three (or twenty) clients all to the same session. BUT, this isn't the solution, because they'd all the same view of what I'm doing (which is amusing at first, but useless).But, hooray, introducing another tmux concept, "groups". "Groups" are groups of sessions, that contain the same windows, but do not have to share a view.
Now I open my three gnome-terminals. In the first one I do and likewise for the second and third.And if I feel like working from my laptop, I vpn+ssh to my desktop, and just attach another tmux client to foo1 or foo2 or foo3. This one shares a lock-stepped view with the session it's attached to, but who cares, I'm not watching the desktop. Tmux resizes every session to the minimum-sized attached client, so it's important that I detach my laptop-client when I wanna go back to my desktop. If I forget, no problem, tmux lets me do that from either keyboard (though I have to look up the syntax to do it from my desktop's keyboard).
So, 5 things to look at, 3 or 4 views into those things, arbitrary swapping each to the other. I haven't been using this very long. It's GLORIOUS. Does that help?
[1] https://syme.herokuapp.com/
This is especially true because when people who view these slides google for more information, and they google for "tmux screen", they're gonna get rants about tmux vs screen.
EDIT: also, I would suggest renaming this to "elementary uses of tmux explained". Because obviously this is like 1% of the use of tmux (but the best 1% to start with, imo!)
He likes it, but it also frustrates him; it crashes semi-regularly, it sometimes locks out input when one program is spamming one of the tiles, and due to it intrinsic nature you can no longer select-copy large blocks of text with the mouse if you have any vertical splitters.
The lack of block text select-copy is alone enough to keep me away.
Most of the other benefits can be gotten with screen, with better reliability and performance. I use several customized .screenrcs for various tasks, to get started up quickly every reboot. But I don't run screen in every terminal because native scrollback buffer is too valuable.
I feel the exact same way. Scrolling inside screen is just a pain :(
I do this all the time to e.g. select deleted files from a git status command so I can xclip paste the selection out through awk to xargs git rm (or rather, use some scripts which simplify the above). Similarly for rspec / cucumber test results to extract out the failures for use with $(<failures.txt) on repeated runs as I fix broken tests. I have a script that analyzes ruby stack traces, which I copy from the crashed session. All sorts of ad-hoc clickery, I rely on word wrap being detected consistently.
Not sure I understand why people would be so excited about this tool?
It also offers other convenient session management functions like multiplexing of multiple shells (maintaining a separate screen image and scrollback for each), cut-and-paste, etc., but the above is the big one I think.