I use screen and tmux for different tasks.

I'll use screen when I need to run a long-running task and can't keep my terminal session open.

I use tmux with a script so that I can ssh into multiple nodes and broadcast the same commands to them all at the same time. Great for interactive deployments that I haven't been able to automate away with CFEngine just yet.

So why do you use screen rather than tmux for long running tasks, if you use tmux for everything else?

Force of habit more than anything else. I just learned about tmux a month ago when I needed to find a way to implement that broadcast solution. For the moment, broadcasting is the only thing I use tmux for - Just as detaching from long running sessions is the only thing I use screen for. I don't have an allegiance to either as most of my tasks I do in a single terminal window.

> I use tmux with a script so that I can ssh into multiple nodes and broadcast the same commands to them all at the same time.

I sometimes need to do this with multiple VMs. I'm really, really not in favor of bash scripting, but I've found the following to suffice, without the tmux dependency:

    for host in box1 box2 box3; do ssh $host 'command; command; command'; done

(This presumes you've set up ssh-agent or are using passphraseless keys and suitable stanzas in ~/.ssh/config; adjust to taste if not.)

I'd never heard of using tmux in this fashion before. Is it that the task sufficiently resembles a nail, or does tmux provide some unique benefit here?

That tmux broadcast trick sounds interesting. Are you able to provide some more details about it please?

Pull up the command line with "Ctrl-b :" Synchronize your panes: "setw synchronize-panes on" Now you can send the same commands to all panes in the current window. To turn synchronization off: "setw synchronize-panes off"

My shell script takes in a list of tuples (hostname plus a special id that I need to paste for my tasks that's unique to each host), splits off a window pane for each hostname(tmux split-window -h), ssh's into each host in it's own pane, and turns on synchronization.

I did a little trick to setup pastebuffers to hold that special id from the tuple i passed in. And setup keybindings so that I can press a key combination to paste in that ID whenever I need it to each respective pane.

If I ever need to temporarily remove a pane or several panes from the syncronized session but keep the others synced, I just change focus to the pane I want to unsync and put it into copy mode with "Ctrl-b [". Can take the pane back out of copy mode by hitting "q".

So far it's made me much more productive when I have to run a bunch of identical commands on a cluster of nodes for which we have no defined process (i.e. I'm figuring it out as I go).

I'll need to sanitize the script, but I'll try to put up a github gist of the script later on.

Thanks for that :)

> I'll need to sanitize the script, but I'll try to put up a github gist of the script later on.

If you wouldn't mind, I'd be hugely grateful as I often find myself having to do similar tasks as what you describe (and even wanted to set up a script to auto start sessions in different panes like you do but wasn't aware that was possible).

While I do use tmux quite heavily (to the point where I found myself needing to rebind a lot of the keys to be more vi like or more convenient to manage one handed), I reckon I still only use about 10% of it's functionality. So it would be good to see other solutions based around tmux.

So, for those looking to make synching easy, you can add this to .tmux.conf

    bind S setw synchronize-panes

Without the on/off option, it acts as a toggle, making it a keystroke away.

I didn't know about it either but found this:

https://twitter.com/j_melis/status/179173797285478400

Seems like a neat trick

if you're running it on linux, is any reason to use screen for long-running tasks, instead of Docker?

The reason folks asked, "docker is a screen replacement?" is because one typical use case is using screen within an ssh session where you might get disconnected. screen holds onto the session so that you can ssh back in and continue from where you left off.

    $ ssh hostname
    $ screen
    # some time later, you get disconnected...
    $ ssh hostname
    $ screen -x
    # back to where you were before getting disconnected.

Screen is amazing for SSH work or if you just don't want to have 50 tabs open. I've been looking into tmux lately though for the later. I just found out about it last week.

Seriously, the amount of commands linux has that most people don't know about is staggering. This link[1] was on HN just the other day.

[1] http://www.danielmiessler.com/blog/collection-of-less-common...

I use tmux at work to manage at times up to several dozen sessions each with several windows/panes (I make one session for every conceptual task that I take on, and sessions live until I complete the task). In my experience it is much more robust than screen (not as many dungeon collapses, if you know what I mean) and well worth switching to.

Don't forget mosh exists if you're commonly in situations where a normal ssh session is unreliable: http://mosh.mit.edu

mosh + tmux are simply amazing together. It has radically improved my life, where I keep persistent connections from my laptop to various remote machines.

My only complaint with mosh is how slow it is - my top-level 266x188 tmux session absolutely crawls on it, and it's quite common to see it using more CPU than whatever heavy task is spewing out lots of tty output. Wonderful for the common case, though.

Docker and screen do completely different things, unless you mean some other Docker than what google found for me.

Docker runs a whole container (with embedded OS), screen justs keeps a terminal accessible after a disconnect. I don't see how using Docker fits that usecase.

Docker can be used as a screen replacement?

I'm a heavy Docker user.

I'm using screen right now to scp 4.5Gb from home to my Docker host. I'll close the terminal at some point and check progress tomorrow.

I guess you could do that in Docker.. but why would you?

I haven't explored Docker yet. Some of my team members have been looking into it. Hoping to read up and experiment with it a bit once I have some free time.

I also use byobu but byobu uses preconfigured screen or tmux configuration. You can choose the tmux or screen backend with the commands byobu-tmux or byobu-screen.

Byobu is a pre-configured 'easy mode' for either Screen or Tmux.

I use it all the time on my RasPi at work, running a mutt instance. I can hop in from any machine and have my 'native' email client accessible.

tmux is very scriptable. I have a shell script "go". go <box> opens new tux window splits it twice (3 total panes) all ssh'd into box, one as root, one tailing log files. The "go" script has grown over time, running custom log tails on specific boxes. And one command "vroom" which ssh's into web and db boxes running atop, apachetop, pg_activity in a bunch of panes.

It's just an example. Tux lets you automate interactive shells.

I'd love to see that script. I'm a long time screen user and would love to find a few examples that'll show off what tmux makes easy.

I have switched from screen to tmux and tmux IMHO more convenient (I have about 30 windows in 2..3 tmux sessions). Can't say anything about byobu.