Tmux, for fun and profit | Hacker News Reader

Tmux, for fun and profit

reefpoints.dockyard.com

97 pointsphsr71 comments

I am going to go out on a limb and say this article has little to no content. I am surprised that it has 69 points despite being very light on content.

More over, the comments here are mostly tangential to the article (except in the sense that they involve the word tmux).

Am I totally wrong? Can everyone else see into this article where I can't?

He explains how he uses tmux for pair programming. Seems useful to me.

He says he switched from screen to tmux, then describes very shortly a use case in which tmux does not bring any benefit over screen (sharing a vim session).

More often than not, I upvote submissions only to influence what's discussed on the front page. Many comments are far more in-depth than the original article however tangential they may be, but the topic has to be brought up.

I found this to be a far superior article: http://news.ycombinator.com/item?id=3824399

It's rather amusing that your link has only seen 3 up votes. That's a real shame.

This post got me thinking about building a remote dev system using tmux running on EC2 or some other cheap VPC host. I like the idea of pulling up a fully configured dev system from anywhere. Mainly so I can pick up the same session from home or work for hacking on my own projects, rather than keeping two separate systems in sync.

Does anyone else do something like this?

    > Does anyone else do something like this?

Yup - I do exactly this for about the last year, and it works as you describe. Long-lived IRC sessions, all of my editing windows open as I like them. You can have nice monitor/chair/keyboard setups at work and home. I find I don't have much use for a laptop any more. If your Windows/ubuntu desktop install breaks, you can reinstall quickly and get back to where you were.

I hope I never need to get back to my Windows/Ubuntu install...

What I mean is - whatever is driving your graphics card, monitors and local network. Sometimes I do a dist upgrade and my video drivers go to junk. Or family install something to my workstation and I find that it has added junk to the boot sector, and I want to get rid of it for sure. Or my mac laptop just starts being really slow for reasons I can't be bothered to investigate. These things are no longer an issue because your desktop install is expendable.

Definitely do not want to get back to my ubuntu machine with proprietary video drivers.

I do this on a linode and have been quite pleased. I've found TMUX/git/Vim to be an awesome way to keep an environment up to work/play with from anywhere, while not having to worry about leaving a machine constantly running at home.

I've also experimented with Cloud9 to some success, but it will depend on the nature of what you're doing.

That's the premise behind http://pair.io

I do this a lot, particularly with projects that use a database that might be hard to configure (and the configuration isn't fully scripted). Just get the development version of the DB right once, and then make a copy of the machine in case you mess things up later and need to revert. It's saved me a lot of DB rebuilds, and I don't have to do DB migrations on both my laptop and desktop to keep them up-to-date so that I can run tests from either.

I'm doing this now!

I've got a linode box running arch. I configured it with all my dev needs. I'm currently in university and I spend a good amount of time at school, bouncing between labs and then also working from home.

Right now the process is simply:

  ssh me@mydomain.com
  tmux attach

Up comes a familiar |- split console with vim running in a window, a terminal at the root of whatever project I'm working on and the server output of that project below it. If I have to leave suddenly, Ctrl+A+D and walk away. It'll be there when you log in next time.

It also has huge advantages if you're working remotely with teams or just want to launch stuff. I have nginx already configured and running. When I need to launch a new project:

1) Go to the Linode DNS Manager and setup a new subdomain

2) Go to /srv/http and git clone my project

3) Edit my nginx.conf, reboot nginx and done.

Some stuff worth checking out:

* https://github.com/thoughtbot/dotfiles

* http://www.thegeekstuff.com/2009/04/ctags-taglist-vi-vim-edi...

Edit: formatting

A small addition: use a wildcard DNS entry and you can skip 1).

That's exactly what I want, a remove dev box for working on and serving up web projects. I'm setting this up on an EC2 micro instance right now, slowly getting a feel for the tmux key bindings. Thanks for those links, great stuff!

My comment from the blog post:

tmux and screen both have upsides and downsides for pair programming. Ones that I know of:

1. screen requires itself to be setuid root for session sharing. This is security issue to say the least. The frustrating part of this is that screen explicitly checks that that uid == 0. This means that, even if you can iron out all of the permissions issues between you and your partner without needing root access, screen will only accept suid root as the solution.

2. When you are screen sharing in tmux, the configuration used is the configuration of the person hosting the session. This can suck if you have a lot of non-standard bindings, because it forces the person you're pairing with to know them too. screen allows you to both use your own configurations while being connected to the same session.

One way we are going to get around this is that we plan to have a golden .tmux.conf that we will all use at DockYard, so that any non-standard bindings will be standard to us

Regarding #1: if you are doing software development on a system with any security requirements at all, you have already lost. Maybe I can see bending that rule for debugging a live system in extremis, but not for "pair programming".

  > if you are doing software development on a
  > system with any security requirements at all,
  > you have already lost

Could you expand on how security and development are diametrically opposed to each other?

If my development server is exposed to the Internet and I do something like disable root logins in ssh, why/what have I 'lost?'

A box under development can and will have all sorts of terribly insecure behavior. It shouldn't be on the internet. I'm not saying you "lose" anything by trying to secure it, I'm saying that you already "lost the [security] game" when you put the box on the unfiltered internet in the first place. Your goal should be limiting exposure when it is compromised, not trying to lock down hatches on a leaky hull.

Specifically: dickering over whether or not to make screen suid root on your dev boxes is an exercise in needless optimization.

> Your goal should be limiting exposure when it is compromised, not trying to lock down hatches on a leaky hull.

But isn't running applications only as regular users just that, limiting exposure?

  > Specifically: dickering over whether or not to make
  > screen suid root on your dev boxes is an exercise
  > in needless optimization.

Are you speaking from the point of view of a 13 person startup, a 200 person business or a Fortune 500 corporation?

3. Both pairs get access to whatever user starts tmux. This may or may not be a problem, but it was with me as we were pairing on my personal machine and I didn't feel comfortable giving complete access like that.

What we came up with is creating a new "pair user" and running tmux within that.

The configuration wasn't a problem for us since one of us hadn't ever used tmux and had therefore had no opinion.

  > Both pairs get access to whatever user starts tmux

IIRC, if you 'host' a (gnu) screen session, then your pair will create new shells as your user. This is not a tmux-only issue.

  > What we came up with is creating a new
  > "pair user" and running tmux within that.

That's an idea that I had, but hadn't attempted to look into yet. This also gets around the screen suid root issue (though not necessarily the config issue), if you're both logged in as the same user. How has this been working, any caveats?

  > The configuration wasn't a problem for us
  > since one of us hadn't ever used tmux and
  > had therefore had no opinion.

I use ` instead of C-a/C-b in both screen and tmux, so it could be a bit jarring to others.

> That's an idea that I had, but hadn't attempted to look into yet. This also gets around the screen suid root issue (though not necessarily the config issue), if you're both logged in as the same user. How has this been working, any caveats?

I'm not sure why you need to set suid on tmux. Before we created the pair user I just used the -S option to specify a socket path and then chmoded the created socket so my pair could access it.

So far so good with the new pair user. The only thing that's different is that to push our changes up to the main repo we need ssh keys and we haven't gone through the trouble of creating a new ssh key for the pair user and adding it to our teams github repo, so we have to git push and pull from a non-pair login. That can be fixed when it gets annoying but so far I'm always logged in to that machine as myself as well as the pair user so I can just switch tabs and git push/pull when needed.

> I use ` instead of C-a/C-b in both screen and tmux, so it could be a bit jarring to others.

I use C-\ myself since C-a and C-b are both prominent Emacs keys.

  > I'm not sure why you need to set suid on tmux

I guess I should have been clearer:

  > This also gets around the "GNU screen" suid root issue

You can easily fix this. You can:

1) Use a combination of ssh-agent fowarding and manually exporting the $SSH_AUTH_SOCK variable to switch between two users' ssh-agent sockets.

2) Each user commits from a separate window/shell. Each window/shell has a separate ssh-agent running in it, with that user's ssh key ssh-add'd to it.

Though, options 2 is less secure.

For #2 - there is WeMux (https://github.com/zolrath/wemux), a shell script wrapper over tmux. I am not an expert, so cannot point out how (in)effective it is in terms of applicability or security.

I'd add:

3) Tmux sessions are restricted to the size of the smallest client connected to the session. We've recently started using it at work and it works fine for 2 of us, but 2 others found that the resolution differences between their 13" and 15" macbooks means that the 13" sets the tmux session size so the 15" doesn't use the whole screen.

I'd experiment with different font sizes to match the line count.

I'm pretty sure this would also be an issue with screen. The pair maybe able to operate on separate 'windows' at different sizes, but would not be able to view the same window at two different sizes at the same time.

Actually Screen is even worse; it sets the size to whoever joined last. So if someone with a big screen joins a session of someone with a small screen, portions of the window will be invisible to the person who started it.

C-a F will resize screen window to size of your terminal.

Remote pair programming sucks. I don't know why there isn't a higher level protocol that would send simple tab changes, text highlights, text deletion, and other high level common tasks. This way the two connected programmer could actually be using different editors but still experience the same editor actions. And each user could maintain their own separate key bindings.

Who cares if I press cmd-t to open a file or my pair prefers to open a file with cmd-shift-n? Just send me the action that a file was opened.

I wrote up my detailed thoughts on fixing remote pair programming here.

https://gist.github.com/1999816

  > Who cares if I press cmd-t to open a file or my pair
  > prefers to open a file with cmd-shift-n? Just send
  > me the action that a file was opened.

I don't think that this was an affirmative design decision. I think it has to do with the architecture of software, and is merely a side-effect of that architecture. Pair programming isn't the main use-case for terminal multiplexers.

As with Google Documents where you can see other changes in real-time?

Yes and no. Would be really fun for five minutes and really irritating for the rest of the time.

That is what pair programming is about. Collaborative changes in real-time.

I would say that pair programming is primarily about close collaboration between people, code is just an artifact of that.

I've used tmux and screen on occasion, but I can't get past the fact that they don't fit well with GUI terminals. I love having "GUI" scroll-back, which I can go through with mouse scroll-wheel, or just dragging the scroll bar up and down.

You could enable the mouse for mouse interaction with a supported terminal. In my tmux config:

  set -g mode-mouse on
  setw -g mouse-select-window on
  setw -g mouse-select-pane on

This particular configuration will allow you to scroll, select text and focus windows and panes with just a mouse click.

Except you can't natively select text for copy/paste anymore.

When you click-drag you're now triggering a tmux selection, not the native terminal-emulator highlight. This is a big problem because the emulated variant is slow and behaves nothing like the real thing.

To my understanding this is also a problem that can't be solved without further terminal emulator support. As it stands the remote application (tmux) can either receive all mouse-events or none of them.

This means you have to choose between scroll-wheel support plus broken text-selection - or no scroll-wheel support.

I tried the mouse integration and turned it back off for the same reason as you. Not having copy-paste at the terminal level is a non-starter as far as I'm concerned. Learning the vim movement commands better eliminated most needs for the mouse-pointing ability anyway.

Learning the vim movement commands better eliminated most needs for the mouse-pointing ability anyway.

Sadly not for me. I'm a die-hard vim-user but I can't live without my scroll-wheel in the terminal.

Same here. But I found a decent workaround.

I have following in my .tmux.conf:

   set -g history-limit 1000
   # See https://wiki.archlinux.org/index.php/Tmux#Scrolling_issues
   set -g terminal-overrides 'xterm*:smcup@:rmcup@'

Now I can scroll using "scroll bar" which is acceptable for me. Plus I also get native text-selection.

Agreed, it's a bit cumbersome scrolling and copy-pasting. It is nice to be able to scroll your panes independently though.

Agreed. This comment has a solution (if you use Mac OS X and iTerm2): https://news.ycombinator.com/item?id=3823013

This is cool and something I didn't know about tmux:

"The one disadvantage of everyone at DockYard working remotely is that you can't just turn around and ask someone to come to your desk to pair up. Tmux allows multiple users to connect to a specific session. With a bit of dynamic DNS magic, port forwarding, and ssh tunneling, multiple people can connect to the same tmux session, work in the same vim window, and see the same development server."

...

"With a tmux, ssh port forwarding, and Google+ Hangout, you can create a useful pair programming environment with your remote coworkers. We find this setup very effective and use it often to work together and tackle an issue."

I've found skype and copilot both to work well for this challenge. Curious of tmux will work better (iOS devs).

I also use tmux to conduct remote code-pairing interviews -- very similar to regular pairing except that I've never worked with the candidate before.

Just out of curiosity and without creating yet another HN Poll; Who prefers Tmux over Screen and why?

My preference for tmux is solely based around Brian's book. It was the first time that I actually "got" terminal multiplexing.

Going to once again pimp this book and it's delectable goodness. It's a wonderful book, well written, clear, concise, and in just a few pages, gives you a lot to work with. Highly recommended.

http://pragprog.com/book/bhtmux/tmux

Looked at the book.

We had an article recently about (technical) books being blown up to fill pages - this obviously wasn't.

I don't doubt that this might be a great work, but I have to admit that I felt the '88 pages?' thought coming up. The price isn't too bad. I just found out, while checking out the pragprog site, that I fell for the 'Seems thin' thing. Maybe a conditioning I need to correct - I don't know.

I do, having used screen for a couple of years before switching. It has vertical splits, a saner config, and was easier to get colors working the way I wanted them to. I can also appreciate that it has a more modern codebase with less legacy baggage, even if the benefits of that aren't readily apparent to end-users.

> It has vertical splits

So has screen and has been for years. tmux just had it first.

> a saner config

I never had any trouble configuring screen to do anything I needed.

Can you give a practical example of what somewhat important for the average user you can do in tmux with less effort than in screen?

I used screen for five years and could never internalize the copy/paste key bindings for scrollback, and screen doesn't let you configure them. I was more comfortable in tmux after an hour than after years of screen due to it being able to just work with Emacs bindings.

Apart from this, most of the advantages are only noticeable in a multi-user setup. The socket-based session sharing is great, (it just uses unix permissions) and the fact that it automatically resizes to the smallest display is a huge usability improvement. When we paired with screen we would always have to jump through hoops to make sure the guy with the smaller display joined last or he'd be unable to see everything.

I've still not run into a `screen' installed anywhere that has vertical split support compiled in. Yes, you can get a version of screen that does -- but EVERY version of tmux has vertical splits.

I've been trying out the iTerm2 author George Nachman's mod[1] to tmux that allows integration with terminal emulators (currently only iTerm2). Practically this means that when I reconnect to a server I get a window full of tabs for that tmux server. Now I don't need to know any of the tmux commands. I can switch/open/close tabs using the standard OS tab control keys. I can use two finger scroll to view the history. I can search the history using the usual OS key. I've been dreaming of doing this for gnome-terminal/tmux for years. Someone beat me to it and it's as nice as I had hoped. Of course you can still attach in the usual way if needed.

[1] https://code.google.com/p/iterm2/wiki/TmuxIntegration

They aren't really competing products. Tmux is a Screen rewrite. Screen isn't going to be receiving major revisions going forward, it's (supposedly, I don't play with that code) in an unmaintainable state. That's the only reason tmux was ever created.

No necessarily. There's also the licensing issue. tmux is BSD and screen is GPL. There's a lot of Linux-BSD kerfuffles over the licensing differences.

Less lag in tmux than screen, in my experience.

1. tmux does not require suid root for multi-user. Even if you solve all of the permissions issues for screen, there is an explicit check for uid == 0 when you attempt to enable multi-user.

2. tmux has vertical splits. Yes, screen has these, but they require you to patch/build your own screen. I've yet to come across a patched screen that has vertical split support.

3. tmux can integrate scrolling with iTerm2 (IIRC, there may also be some urxvt integration, but you'd have to verify that).

4. In tmux, splits are first-class citizens. You can do "C-b <space>" to switch between 'layouts' much in the way that you would in a tiling window manager like xmonad.

5. tmux remembers your splits/layouts when you detach/reattach. Screen doesn't last I checked.

6. tmux has a 'show-messages' command that has a log of all messages that it showed at the bottom, so that you can view them if something popped up that you missed.

7. I like the config format better. I was able to convert my highly modded screen config to tmux in an hour or so, and the config file is much smaller/simpler.

8. When scrolling in copy mode it tells you where you are in the scrollback buffer (e.g. "0/32").

9. tmux has this (from the manpage):

  has-session [-t target-session]
                     (alias: has)
               Report an error and exit with 1 if the
               specified session does not exist.  If it
               does exist, exit with 0.

10. Also this:

  respawn-window [-k] [-t target-window] [shell-command]
                (alias: respawnw)
          Reactivate a window in which the command has exited (see the
          remain-on-exit window option).  If shell-command is not given, the
          command used when the window was created is executed.  The window
          must be already inactive, unless -k is given, in which case any
          existing command is killed.

Can someone please explain why dynamic DNS, port forwarding and SSH tunneling involved when attaching to the same session?

I just fired up two instances of Putty and see my keystrokes replicated within a second.

Are you in two separate locations connected to two different networks at the same time? The author is talking about telecommuting. Sure dynamic dns is not needed but timsbox.dyndomain.com is a lot easier to work with than whatever IP he has today.

also the IPs will change over time. The dynamic DNS will not.

Ah I see now, thanks. You don't need any of this though if you have a dedicated development/staging server, which is I prefer.

Does Mosh (posted yesterday) support multiple connections? I know it can suspend resume like screen/tmux. Seems like it would be preferable if it does.

``Mouse free environment'' is a retarded concept.

And that book doesn't understand anything about tmux and why it came about.

What's wrong with striving for a more 'mouse-free environment'?

And what about 'tmux and why it came about' is missing from the book, in your opinion?

Sounds implied you do understand it better, so don't keep it to yourself.

Also, mouse-free environment is not just a concept, and most certainly not retarded. Care to elaborate why you think that?

Reply on news.ycombinator.com