Tools I Use - tmux(rdegges.com)
rdegges.com
Tools I Use - tmux
http://rdegges.com/tools-i-use-tmux
60 comments
I actually use Emacs and shell-mode to do exactly this. It has its own advantages and disadvantages, and only makes sense for people already using Emacs, but it's definitely something to consider.
A neat trick: by default, C-u M-x shell opens a shell with a custom buffer name in another window (in Emacs, the different panes are called "windows") in a specified directory. If you're editing a file remotely with TRAMP, the shell will be opened remotely as well.
I find this really useful when I'm editing multiple files on multiple remote systems and need to run some commands. This also integrates well with the rest of Emacs, making working with multiple shells, different files and other stuff really easy.
A neat trick: by default, C-u M-x shell opens a shell with a custom buffer name in another window (in Emacs, the different panes are called "windows") in a specified directory. If you're editing a file remotely with TRAMP, the shell will be opened remotely as well.
I find this really useful when I'm editing multiple files on multiple remote systems and need to run some commands. This also integrates well with the rest of Emacs, making working with multiple shells, different files and other stuff really easy.
I tried tmux earlier today and found a very nice feature:
I have an SSH session to a remote linux server from my computer, then connect a new SSH session from my BlackBerry, and run 'tmux attach' in it.
The tmux session on the computer resizes to the size of the BlackBerry terminal, and both PuTTY and BBSSH show the same content, and both can interact with it.
Disconnect the BB, and the computer terminal resizes back to what it was.
I have an SSH session to a remote linux server from my computer, then connect a new SSH session from my BlackBerry, and run 'tmux attach' in it.
The tmux session on the computer resizes to the size of the BlackBerry terminal, and both PuTTY and BBSSH show the same content, and both can interact with it.
Disconnect the BB, and the computer terminal resizes back to what it was.
I do the same from my Android phone (using ConnectBot): I can run some long-running process and keep an eye on it while I'm out in the kitchen making a cup of tea. When I'm back in the office, I detach the Android session.
I went from "Terminal" to "screen" to "tmux" to "stumpwm". Baiscally, what I really liked of tmux is the way I could frame my terminals logically or fullscreen easily. I also really enjoyed the fact that I had multiple "workspace". Basically, my WM was just not appropriate for the way I liked to work. Stump fixed that. It's dynamic, I can hack it from emacs and it has everything I liked about tmux. Obviously, I'm talking from my desktop perspective, if I'm working somewhere else remotely it's a different story.
I use screen regularly, but mostly to be able to attach and detach to sessions as I move between work, home, etc.
tmux users frequently tout its ability to do nifty split screens and other window management, but I'm not sure I understand the value of doing this over just starting another iterm2 window/tab and using regular window management tools. Cmd-tilde or Cmd-tab is one less key than Ctrl-a, h.... :) What am I missing?
tmux users frequently tout its ability to do nifty split screens and other window management, but I'm not sure I understand the value of doing this over just starting another iterm2 window/tab and using regular window management tools. Cmd-tilde or Cmd-tab is one less key than Ctrl-a, h.... :) What am I missing?
Good news for iTerm2/tmux users: the next version of iTerm2 (according to the author) has deep tmux integration: http://groups.google.com/group/iterm2-discuss/browse_thread/...
Additionally, iTerm2 supports splitting windows vertically and horizontally, with niceties like dimming inactive panes. However, not all terminal applications support this. When I move from my laptop to a public computer to my iPad I appreciate a consistent experience. If you don't use split windows in the first place then tmux's functionality won't thrill you, but as someone who logs into my dev machine from multiple locations I prefer to rely on the actual terminal application and host operating system as little as possible for window management.
If you do dev work on a remote server this is usually not an option unless you're willing to open half a dozen ssh connections, but then none can communicate with each other easily..
I'm sure iterm2 does a fantastic job doing window/tab management, but I spent almost 5 years working over ssh.
edit - tmux is scriptable too, so you can setup a dev environment using a shell script (I do this, setting up my rails server, console, resque workers, etc, etc).
I'm sure iterm2 does a fantastic job doing window/tab management, but I spent almost 5 years working over ssh.
edit - tmux is scriptable too, so you can setup a dev environment using a shell script (I do this, setting up my rails server, console, resque workers, etc, etc).
The other awesome thing about tmux is being able to use it for remote pairing with vim or emacs. When working remotely, I use this a lot.
There are multiple problems with tmux on OS X. pbcopy and pbpaste, for instance, are entirely unusable. Even if tmux has some nice benefits over screen, it probably isn't worth it to the Mac user to switch.
Looks like there's a fix for using pbcopy and pbpaste with tmux on Mac OS X: https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard
There's a similar-sounding problem in the X11 environment on traditional Unix systems: the current default graphical display is in the $DISPLAY environment variable, while authentication information is in ~/.Xauthority. GNU Screen tends to blindly inherit those settings, so you can freely start GUI apps from inside screen and have everything work... until you try to reattach screen from inside a different GUI session, or from a non-GUI session (say, ssh). Then all the processes you run inside screen go looking for a GUI session that no longer exists and everything starts breaking in odd ways.
tmux actually has a way to work around this: whenever you reattach, it looks at a whitelist of environment variables representing external resources, and either updates its own environment with the new values, or removes those settings from its environment if the place you're attaching from doesn't have them available (naturally this doesn't magically fix any processes already running inside tmux, but every new window you create will be set up correctly - unlike screen, where you have to kill every window and end the session). By defaut, this whitelist includes variables used for X11 authentication and the SSH agent. If OS X has a similar environment-variable-based connection system, you might be able to add it to tmux to get things working.
tmux actually has a way to work around this: whenever you reattach, it looks at a whitelist of environment variables representing external resources, and either updates its own environment with the new values, or removes those settings from its environment if the place you're attaching from doesn't have them available (naturally this doesn't magically fix any processes already running inside tmux, but every new window you create will be set up correctly - unlike screen, where you have to kill every window and end the session). By defaut, this whitelist includes variables used for X11 authentication and the SSH agent. If OS X has a similar environment-variable-based connection system, you might be able to add it to tmux to get things working.
GNU Screen allows you to do something similar using its setenv command. For instance, to update the value of $DISPLAY to a new ssh session's value you could run "screen -S foo -X setenv DISPLAY $DISPLAY" before running "screen -r foo".
I have a wrapper script that reproduces tmux's behavior of automatically updating a set of environment variables. It goes a step further and also updates them in your running bash shells. For this to work you have to register a signal handler in your .bashrc that sources a file with the new environment. The script is available at https://github.com/sciurus/splatbang/blob/master/rescreen
I have a wrapper script that reproduces tmux's behavior of automatically updating a set of environment variables. It goes a step further and also updates them in your running bash shells. For this to work you have to register a signal handler in your .bashrc that sources a file with the new environment. The script is available at https://github.com/sciurus/splatbang/blob/master/rescreen
You can use this for that:
https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard
The documentation recommends changing tmux's default command, but if that weirds you out, a simple alias to "reattach-to-user-namespace pbcopy" also works.
https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard
The documentation recommends changing tmux's default command, but if that weirds you out, a simple alias to "reattach-to-user-namespace pbcopy" also works.
Instead of trying to make the native copy/paste work, can anyone think of a way to set up key bindings in OSX to mimic copy/paste but store the text in /tmp/mypasteboard or something?
Would AppleScript do it and would that work in any application?
Would AppleScript do it and would that work in any application?
What I don't understand is how both screen and tmux ship with bindings that conflict with readline. Did nobody notice, or did nobody care? Neither is usable without fixing this in config.
Configuring the prefix key to C-z is quite harmless, C-z C-z for suspend is quite ok.
(As a bonus hint, binding subkeys with control it's faster to send commands: C-z C-n is faster than C-z n, you just keep control pressed during the command sequence.)
(As a bonus hint, binding subkeys with control it's faster to send commands: C-z C-n is faster than C-z n, you just keep control pressed during the command sequence.)
Of course, it's easy to fix. It just boggles my mind that they would have made that mistake in tmux to begin with when you consider that it's one of the main complaints people have about screen and tmux was supposed to be a "better screen".
How about C-q as an alternative? It is same as C-v (in the default readline mapping) and generally unused. It does not conflict even with Windows' use of C-v.
Funny, just went from screen to tmux in one hour, and that was the first the exact same thing I felt odd about :)
So I've recently got into using vim and quite like the split screen features. How would I mix something like this in for doing day to day running commands and editing stuff with a vim split screen workflow?
Sorry if this seems like a difficult question, but even stories of how people manage this would be great :)
Sorry if this seems like a difficult question, but even stories of how people manage this would be great :)
I am a tmux/vim user and I find this a constant problem. Split tmux panes don't allow your vim windows to communicate with each other (you could always fallback to using the system buffer, though that is often insufficient). Yet, split vim windows don't allow a shell in a single window.
Theres actually a vim plugin I've been using that comes with Janus that loads up a shell in a vim buffer. It's been quite helpful, but I still find myself having separate macvim and terminal windows open, especially for rails dev. I normally have vim open for editing and a terminal window open with tabs for rails console, guard for rspec, server and general terminal open.
If you want a shell in a vim buffer, try ConqueTerm: https://code.google.com/p/conque/
Seems to work quite well, both for simple shell-like programs and full screen-oriented commands.
It does depend on a vim with Python support compiled in, but that doesn't seem like a huge constraint.
Seems to work quite well, both for simple shell-like programs and full screen-oriented commands.
It does depend on a vim with Python support compiled in, but that doesn't seem like a huge constraint.
I use vim splits as well. I find my typical workflow is something like this:
1) Open a tmux split (vertical). 2) In the left tmux pane, open vim (and split horizontally). 3) On the right side, have my tests open and running via a watch command, eg: watch -n 10 "nosetests", or something similar.
1) Open a tmux split (vertical). 2) In the left tmux pane, open vim (and split horizontally). 3) On the right side, have my tests open and running via a watch command, eg: watch -n 10 "nosetests", or something similar.
If you like tmux, you may love tmuxinator -- lets you keep your terminal sessions saved (even things like SSH that require login), and resume them exactly as you left.
https://github.com/aziz/tmuxinator
https://github.com/aziz/tmuxinator
The best thing I ever did in tmux, was to set a myTerminal variable in xmonad to "urxvtc -e tmux".
So every terminal window I open already has a tmux inside and I never have that "oh, it would be nice if I haven't forgot to turn tmux on" feeling.
So every terminal window I open already has a tmux inside and I never have that "oh, it would be nice if I haven't forgot to turn tmux on" feeling.
Or if used localy, go all in and install XMonad or Awesome. And get ALL your apps/windows tiled !
tmux is amazing. A really handy command is send-keys. I use a fullscreen split pane setup with VIM in one and elinks in the other.
Inside my .vimrc:
Inside my .vimrc:
command W :w<Bar>execute 'silent !tmux send-keys -t 1 C-r'<Bar>redraw!
Many previous discussions: http://www.hnsearch.com/search#request/submissions&q=tmu...
I've been playing with byobu and I like it a lot.
http://blog.dustinkirkland.com/search/label/Byobu
You can use either a screen or tmux backend.
http://blog.dustinkirkland.com/search/label/Byobu
You can use either a screen or tmux backend.
I used screen for 15 years but recently switched because I liked tmux's easy-to-read conf file and scriptability.
Mac OS X users watch out, launchctl commands barf mysteriously inside of tmux.
Mac OS X users watch out, launchctl commands barf mysteriously inside of tmux.
This should be added to a FAQ somewhere. Took me ages to figure it out on my own, especially since the error msg is so generic -> http://pig-rabbit.com/tmux-and-launchctl
Just use https://github.com/ChrisJohnsen/tmux-MacOSX-pasteboard. Works for pbcopy, pbpaste, and launchctl.
Then just alias launchctl to "reattach-to-user-namespace /bin/launchctl"
Then just alias launchctl to "reattach-to-user-namespace /bin/launchctl"
I absolutely love tmux and use it everyday, but the killer feature I really want is tighter integration with a terminal emulator like iterm2. I would love to be able to attach to a tmux session with iterm2 and scroll using two-finger scrolling, while still being able to detach from the session and re-attach remotely.
It would seem like this would be a possibility given tmux's design, which is a lot more flexible than GNU screen's.
It would seem like this would be a possibility given tmux's design, which is a lot more flexible than GNU screen's.
Your wish has been granted. See some of the recent nighties for iterm2 and associated discussion in the iterm google group.
I keep having this nagging feeling I should use tmux more often. Right now I use it for remote pairing type stuff, but I can never bring myself to use it regularly. I love tmux, and it's super useful, but I just can't deal with the way it breaks scrolling. tmux and screen both horribly break scrolling and reverse searching. I'm not sure what the fix is, but until that works I can't see myself using it regularly.
CTRL+B (or whatever key to get into tmux mode input) then Page Up/Down to scroll or keyup/down. Then just esc when you are done scrolling.
Works fine here, havent needed to mock with settings to make it work like this. But the tildas scrollbar is broken by tmux, and the usual shift+pageup, and mousewheel to scroll... but thats okay.
Works fine here, havent needed to mock with settings to make it work like this. But the tildas scrollbar is broken by tmux, and the usual shift+pageup, and mousewheel to scroll... but thats okay.
"setw -g mode-mouse on" in your tmux.conf will let you use the mouse for scrolling and selecting text once you're in copy mode.
> [...] but thats okay.
Agree to disagree, I suppose...
How do you do reverse search, though? Any replacement for ITerm's Ctrl-F?
Agree to disagree, I suppose...
How do you do reverse search, though? Any replacement for ITerm's Ctrl-F?
When you're in copy-mode (activated by prefix-[ also prefix-pgup as mentioned above) search is like vi or emacs depending on your copy-mode (vi by default I believe).
SO: / to search down, ? to search up. If you want to search from the top down, hit "g" in copy-mode to go to the top of the buffer (in vi mode). "G" to go to the bottom.
These, especially /, are really common conventions. / is used for search by vi, less, Opera (Firefox now too I think), even twitter.com.* My point is that / and ?, and to a lesser extent g/G/etc. soon becomes second nature and are worth learning because they are so common. How do you search backwards from the bottom in iTerm?
See "copy-mode" for more info http://www.rootr.net/man/man/tmux/1
*twitter.com (as well as duckduckgo.com and to a limited extend slashdot) uses some sweet vi keybindings. Try n, j, k, r, etc.
SO: / to search down, ? to search up. If you want to search from the top down, hit "g" in copy-mode to go to the top of the buffer (in vi mode). "G" to go to the bottom.
These, especially /, are really common conventions. / is used for search by vi, less, Opera (Firefox now too I think), even twitter.com.* My point is that / and ?, and to a lesser extent g/G/etc. soon becomes second nature and are worth learning because they are so common. How do you search backwards from the bottom in iTerm?
See "copy-mode" for more info http://www.rootr.net/man/man/tmux/1
*twitter.com (as well as duckduckgo.com and to a limited extend slashdot) uses some sweet vi keybindings. Try n, j, k, r, etc.
CTRL+R ? Like normal. Is iTerm another iProduct? Never used macosx, wouldn't know.
All terminals (GNU/Linux) Ive used tmux on, ctrl+r works, and scrolling as described in previous post.
All terminals (GNU/Linux) Ive used tmux on, ctrl+r works, and scrolling as described in previous post.
I was rather inspired by this and decided to write up my tmux config with org-babel as literate programming. Hope someone likes it: http://justinlilly.com/dotfiles/tmux.html
what i like about tmux:
- its actually faster than screen to startup
- all the stuff everyone lists/knows/blog post
what i dont like about tmux: - it schokes on some weirdo programs while screen seems pretty reliable on anything
thus i end up on screen more often than not
what i dont like about tmux: - it schokes on some weirdo programs while screen seems pretty reliable on anything
thus i end up on screen more often than not
Try modifying your TERM environment variable, I've found it can be quite sensitive to that.
One note though - both screen and tmux introduce some delay making the text appear a tad slower (I'm using it over SSH strictly, no idea about 'native console'), does anyone know the solution?
I think that is more to do with SSH than screen or tmux. I just tested it on a SSH session across the Pacific. No difference whether it is a straight xterm or if it is within a screen session.
Nick, thanks for reply, I'm definitely seeing the difference, I will do more tests to figure our the bottleneck, have to think a bit about how to measure the delay exactly too (currently I'm using SecureCRT as SSH client, should probably try something else)
Big thing holding me back from tmux is the lack of cygwin support for (unfortunately) my work environment. Otherwise, I'd switch cold turkey.
I love using terminal multiplexors, but prefer GNU Screen since it is almost always available wherever I need it. For those interested, I use the following to show a status line -- comes in handy when you want to name difference screens. You can always name a screen using "C-a A"
hardstatus alwayslastline "%?%{yk}%-Lw%?%{yk}%n*%f %t%?(%u)%?%?%{yk}%+Lw%?"I prefer GNU Screen for the nethack mode. It is a shame that Screen does not ship with a nicer hardstatusline by default - you can do some really amazing things there.
I just switched.
The only thing I changed is the prefix to Ctrl-A like Screen.
ftfy - screen supports vertical splits too: ^A |
Only in very recent versions; on most distros it means compiling from CVS.
It's been supported in Ubuntu since at least 10.10, which isn't ancient, but I'm not sure it counts as a "very recent version".
Monitoring background windows: with monitor-activity, monitor-silence, and monitor-content [term], you get a visual notification when there is activity, a certain period of silence, or an occurrence of [term], respectively, in a specified background window. Sometimes I open several error logs in a background window and monitor-activity so I get a notification if anything is written.
synchronize-content: I've only used this a few times but it's a neat trick! With several panes open in one window you can send keystrokes to all the panes at once. I've used this while connected to more than one server to compare the contents or make changes simultaneously. I won't claim this is the safest way to work but it comes in handy.
Managing windows and panes in tmux is pretty painless, in my experience. Resizing, switching, etc. are all very simple. One final feature I like, tho it's trivial, is the "show the time" command (bound to prefix-t). Invoking it gives you a nice big digital clock in a window or pane. I put this below my ttytter pane so I don't lose track of time. :)
I don't know how much of this you can do in screen as I've never used it, I'm sure there's a lot of overlap, but as a sometimes very critical software user let me say: I love tmux.