Just running that command will connect to your server and attach to an existing tmux session, or create a new one if needed, and make use of iTerm's tmux integration, so you can use the standard macOS keyboard commands (or the UI) to do things like switch tabs, make new tabs, close them, make new windows, etc. all using tmux and a single ssh connection. You can press 'esc' in the command window to detach from your session and when you return (just using that alias) all your work is just as you left it.
Use mosh[1] instead of ssh for superior handling of weaker connections and roaming. You close your laptop one place, go elsewhere, switch to LTE, whatever, open the lid and you're back on. Don't even need to reconnect.
Well, that and tunnelling all sorts of other traffic, basically mini-VPN. I use this all the time for a variety of remote systems (or local, I am the remote one).
'tmux' is actually something that runs server-side if you are ssh'ing into something, it should work with any terminal emulator the same way as GNU screen would if you ever used that, e.g. PuTTY works fine for tmux.
When I do this, it opens a new window with the "attached tmux running inside" and the old window is running in "tmux mode". Is it possible to not have a new window open, but use the window where the command is run instead?
I use a tool called tummy (https://github.com/minhajuddin/tummy full disclosure: built by me) which allows me to create a Tmuxfile per project. A typical file looks like this:
I used to use tools like that (tummy, teamocil, etc) but I've since discovered tmux-resurrect. It persists tmux sessions, windows, panes, and a whitelist of non-destructive commands like vim and top across reboots. Now my tmux sessions just organically grow and shrink as necessary and I never worry about having to recreate them.
Of course I can see the case for combining both tools. If you have a lot of projects, and/or want REPLs loaded you might not want them sitting around in memory for months if you're not going to use them.
It is trivial to get working. Just use tmux plugin manager to install tmux-resurrect and tmux-continuum.
It doesn't save anything, it is just a startup script to get your tmux session set up the way you want. You can however, have env vars in the script or source from a particular file. e.g.
I don't believe it does save env vars. However, as an owner of a crashy 2010 MBP, tmux-resurrect saves my bacon several times a week. I very highly recommend it.
I've tried tmux resurrect. Wasn't for me. With a predefined script I can close and open many windows with abandon. Also, creating the initial script is simple enough. I guess different strokes for different folks :)
I've been working on a Tmux manipulation library in Ruby as part of another project of mine, called Appear. Appear can raise any process to the front of your GUI (if your GUI is macOS), even if that process is in a disconnected Tmux session.
I'm also working on a little app that allows you to open files in Finder into console Tmux+Nvim.
To me tmux, like a lot of tools, suffers from bad defaults that makes it less enjoyable to use. One example is not being able to scroll with a mouse. I usually find someone's tmux.conf online and use it, but always run into strange problems that I don't have the energy figuring out. My current conf suffers from the navigation bar going completely black when I try to rename a pane (can't see what i'm typing).
Really wish more tools took care into making solid defaults and not assuming all users are like the ones on their mailing lists.
Is your reply really necessary? It doesn't contribute anything. At least other people having the same issues which you know the solutions but don't share, can benefit. Sorry, it just came out wrong to me.
It contributes to preventing the topic from derailing into "how to configure tmux", which is not what my comment was about. Derailing threads is considered bad etiquette online, it's not just me.
I guess bad defaults have been chosen to maintain stability for previous users. IMHO, man pages should contain a .tmux.conf that demonstrate the "best" usage(s) of the tool.
IMHO man is the most important command in unix and "man man" the first step in learning unix.
That's just how (most) command line tools are. You have to invest some time to configure them. And hopefully you're not the type who will fiddle with the settings too much once you have stuff working. I use GNU stow to install my ZSH, tmux, vim, etc. settings on new computers and it works well for me.
I was able to work out pasting into tmux from the system buffer, but no solutions I've seen for copying out of tmux have ever worked for me. So yes, that's a pretty basic usability issue.
I have a plugin I use for that [1]. I enter copy mode, either by scrolling with the mouse or hitting Prefix + esc. I have the copy mode key bindings set up in vi mode (as is my shell), so I navigate around, hit V to enter visual mode, select some text and hit y. Now that text is in the system clipboard.
There's no reason to insult the project just because the default settings don't behave exactly how you want them to.
I personally like the default mouse setting, but you're completely free to change it if you don't. People have different preferences, that's why there are configuration settings to change things.
I don't think I'm insulting the project by saying I disagree with their defaults. Certainly no disrespect intended.
> I personally like the default mouse setting, but you're completely free to change it if you don't. People have different preferences, that's why there are configuration settings to change things.
Right, but defaults are important. You have to ask yourself why people are using the project. Are people using tmux for its mouse settings? I think people primarily using it for session management. If that's the case, why does it, by default, override my terminal's settings? That just seems like a violation of "do one thing" to me.
As a screen user, Byobu is the best alternative. When I muscle-memoried screen commands the first time Byobu detected my actions and asked if my configuration ought to be changed to use screen bindings. Now that is UX done right.
Well, the nice thing here is that with the integration between vim-test and vim-dispatch is that you don't have to do anything for having the tests run in a separate session. It just works. I mean really you _are_ just having it run in a separate session, just more smoothly.
If the tests pass then the tmux window the tests were run in will just disappear, if not, you get popped back to the quickfix window with the errors listed.
Good question, I assume not, but the plugins work so.... I guess maybe the incredible and prolific Tim Pope well maybe update vim dispatch to work with the background processes.
Prior to that I used tmux for a few years, and screen before that. I suppose the only compelling reason to use DVTM is that it acts like a tiling WM, so if you use one (I use XMonad http://xmonad.org ) the experience is basically the same (mod-h/mod-l to resize, mod-j/mod-k to navigate windows, mod-space to switch layout, etc.).
The main reason I switched is my preference to avoid bloat. DVTM doesn't do everything tmux and screen do, it only does window management. I use dtach ( http://dtach.sourceforge.net ) for persistence. I previously used abduco ( http://www.brain-dump.org/projects/abduco ), but it segfaulted on me a couple of times (months apart, in a non-reproducible way); haven't tried it for about a year, so it might have stabilised.
I cannot use st because it still has corner cases that xterm works well but st doesn't yet, and I find the need to patch the sources hard to maintain when a new release comes out and has refactorings included.
But I must say that st's font rendering of Unicode is more complete than rxvt-unicode or xterm. With the same font configured in all three, st is the one that manages to render the most glyphs of plan9port's unicode sample file. Would be great to have the same in urxvt or xterm.
I've used screen for darn near 20 years now. Have tried to switch to tmux, but even with screen-like keybindings, I end up running into something[0] that makes me switch back because screen is just muscle memory for me at this point.
[0] like switching to a non-existent-numbered screen to get a list of which ones I do have...
I was the same way when I first started using tmux. I just "fixed" the keybindings in tmux to what I was used to and went about my business.
It is slightly inconvenient the first time I fire up tmux (with the defaults) on a new host. I just take a 30 second break, create my customized ~/.tmux.conf, and continue on like nothing happened.
Does anyone run tmux with a tiling window manager for local development?
If so, what are the advantages? I know automating sessions is one of them, as explained in the article.
I am more interested in hearing about interactions with the terminal. You already get good mouse-less window management with something like i3 or xmonad.
How about copy & paste? I use urxvt plugin for this, but I often find myself using the mouse to select and middle-click. Is tmux better?
The tiling window-manager is used for longer running GUI apps - webbrowser, pdf/email viewer, CAD etc and for apps that I don't context switch as quickly. Also for handling the dual monitor setup.
I use screen for managing a consistent cli environment - that could be anywhere - on my dev machine, or sshd to a dev container or cloud box. I also tend to context switch screen environments much more quickly - eg. between edit (vim), compile and run turnaround.
Similar to that, I've seen a lot of blog posts about Tmux and Vim, but I've been itching to see one where they talk about day-to-day. When do they use vim-split versus tmux pane, vim buffers versus tmux windows? I use both, but aren't very systematic...there's a bit of cognitive load when remembering which I'm using and using the different commands to navigate. You can't do diffs with panes and it's nice to use vim buffers instead of tmux windows when editing a series of files.
I imagine using a tiling window manager with tmux you'd have a similar issue. Sshing into a box you can launch tmux and have windows and splits inside, but you couldn't use your WM.
What I do, and would recommend, is spin up vim or emacs as a daemon, then connect to it as a client in one or more tmux windows.
That way, you can yank/put easily using the usual shortcuts from any tmux window to any tmux window. Then, it's usually easiest to only use intra-process pane splitting (keeping it all in vim or emacs) unless you need to do something that doesn't follow a perfect division, like:
top half vim / bottom left vim / bottom right trailing logfile
or something.
More than happy to write a blog post, if you're interested.
Interesting to run it as a daemon and connect. I'd be curious to see how you set it up and use it in practice. Whenever I use vim splits I'm almost always diffing left and right. So, nothing fancy.
Definitely. If you shoot me an email (hello@tedkornish.com) I'll let you know when the post is up. As a disclaimer, I use emacs with evil mode, not vim proper, so the command is just
emacs --daemon=myproject
Then it's just
emacsclient -nw -s myproject ./directoryhere
to connect, and the first part of that can be aliased away. Not 100% sure that vim has a good daemon/client mode, but I seem to recall something existing along those lines. It can be extremely useful to have multiple collections of editor panes set up, each in a different part of the codebase, and the ability to switch back and forth quickly with tmux - really helps for debugging and keeping organized.
I use a tiling WM with tmux and vim. I have three levels of windows/tabs. It's probably not optimal but I've gotten used to it.
I basically always run all my terminals in a single tmux'd window, and run a single instance of vim. I use vim windows when I edit multiple files at a time.
When you spin up a new window with i3, it doesn't retain the previous's current working directory. There are some hacks to make it kind of work, none of which work nicely. With tmux it just works.
tmux has synchronized panes. It allows you to send same keystrokes to multiple terminals at once. This is useful for managing multiple host machines at once, i.e. ssh'ing into different machines at checking certain logs.
Disadvantages:
Double the amount of keybindings you need: one set for i3, one set for tmux. i3 allows you to active a mode where keystrokes are 'forwarded', so theoretically you can use the same keybindings for both, although it is very annoying if you forget to active this mode since you're now creating i3 windows instead of tmux panes and have to clean them up.
I'm writing an i3/tmux integration similar to iTerm2's[0], but working at the WM layer, using i3 and urxvt.
The reason I'm doing this is that I'm often ssh'd into a box, and having to ssh into multiple terminal is a chore. I often create a spontaneous term that I close after a couple of minutes. Being able to have a dedicated ssh'd workspace where every split is ssh'd into the box would be a godsent.
This would also fix the mouse integration and various other things that annoy me with raw tmux.
This would be great if you get it working. I don't suppose you've got a link for what you've got so far in git or anything? I only make basic use of tmux because I'm more comfortable with i3 key bindings.
I'm still stumbling in the dark trying to understand how everything works. Also, the code might be an abomination, my goal was mostly to get stuff working, refactoring will come later.
This project is at once a learning project for many things (tmux internals, Rust, IPC in general, i3 IPC) and a tool I've been really needing for a while, so progress is slow but steady (I mostly work on it in sleepless nights and week-ends).
This sounds cool. Especially for me since i have been using a chrome book with Linux. There is no cmd or windows key so I have to use alt for i3 but then have nothing for vim/tmux navigator.
Since I can't use a tiling window manager everywhere, I do the next best thing: I have a set of key configs for most platforms that gives me (mostly) uniform control over windows, and then use the local terminal emulator with tmux inside.
I use Moom on the Mac with hotkeys that match the Windows left/right-side tiling, and a custom OpenBox config[1] that matches those too:
Then on the Mac I usually use the native Terminal (I keep trying to switch to iTerm, but most of the performance issues Terminal had have been ironed out by now), on Linux I usually use lxterminal, and on Windows I either use Cygwin's mintty or (more recently) wsltty to interact with Bash for Windows:
(even though I'm a Microsoft employee, I strongly dislike the "feel" of the standard console and the way it handles both fonts and copy/paste, so I seldom use it at all)
I also tried various hacks to do raise on hover and suchlike, but I found that some things were best left "native" and get along OK with these bare mouseless window management hotkeys.
Incidentally, tmux has a growing following among my colleagues (there are a lot of Microsoft folk getting to grips with Bash and SSH these days, so when I tried to pass on some best practices, tmux was right at the top of the list)
How do you deal with switching between projects though? I find my self switching between several projects as I'm working through something and suddenly something needs to be done in another project which is blocking someone. Wouldn't tmux + tmuxp (or similar) be more useful than just i3? Or do you have scripts for launching all those windows and putting them in the right place?
I run i3 and tmux. The biggest reason I do this is that I'm much more used to tmux key bindings rather than i3. Moreover, I don't think I'd get any huge benefits by getting more used to i3 key bindings.
Edit for another reason: I use Tmux on my work laptop (OSX) and on my Desktop (FreeBSD + i3), so my key bindings are supported on essentially whatever machine I'm on.
I use a tiling window manager, and mainly use tmux to maintain ssh connections to other servers that I can connect to remotely.
So my main "jumphost" machine has a tmux session with multiple "tabs" logged in to other systems I manage. I can connect to this tmux session from my work desktop machine, from my laptop, or from home (via VPN). Makes it very easy to stop, go somewhere else, and pick up with everything the way I left it. I also don't worry about dropped remote ssh connections anymore (not uncommon at home because I often have to reset my cheap wireless router).
I don't do anything really advanced with tmux. One thing I'd like to know is a good way to deal with tmux within tmux, I have occasionally stumbled into that situation and then it's hard to get the "inner" tmux to do anything because the "outer" tmux intercepts all the key commands.
I do. Part of it is just that I'm so used to it from using it remotely that I feel at home using it locally as well. But it's also very portable. For instance, I can use it in macOS or even on Windows using the Ubuntu bash subsystem. This makes it effectively a universal tiled window manager for me.
I use awesome wm with tmux and urxvt. Tmux has a nice copy mode, which has emacs and vi modes. By default it copies to tmux buffers, but you can set it up to copy to the system's clipboard:
It's rather idiosyncratic but I've gotten used to running all my terminals inside a single tmux window. I spend 95% of my time in either a terminal or Chrome so I basically only use awesome to switch between them, or put a browser and terminal side by side.
I use screen rather than tmux but the principal is the same.
I have set things up so that I maintain separate screen sessions per context, including separate shell histories (the single biggest win, by far), separate shell defaults, aliases, etc.
I was a long time tmux user while on mac. Since I've swapped to arch and i3 I don't use tmux at all, and just use the WM. I basically live in terminals nowadays and I've not really missed tmux. The thing I really do miss is vim-tmux-navigator.
One thing that I like about tmux is using tools like tmuxinator to compose a project-related session where server processes are spun up in separate tmux windows. Do you have something equivalent to this with just i3 or is that just not your use-case?
I use it with Xmonad, for me tmux's scripting and ability to detach and attach to sessions is a big win. It also allows me to run async tests by triggering a test from vim without blocking. And, the copy paste support is also very good.
I do that, not in a real "tiling window manager" but something very close: openbox, set to show no titlebars, and using shortcuts to title the windows to precise positions. I have 3 position: most of my screen on the left, a small vertical slice on the right, a smaller chunk underneath. If I want a titlebar for some application, I have a shortcut that will give the window a titlebar, and then I can move it around with the mouse if I want to. So I get the best of both worlds.
Surprise - I don't run tmux. It is simpler to have several roxterm, in these position, with various tabs open. When I work remotely, I use screen on the remote host, but that's all.
To give you an idea of my shortcuts, in a real life scenario ; my caps lock is remapped to control or escape with xcape:
- esc: pop a new roxterm and from wherever I am, bring me to the terminal desktop
- f9: resize this roxterm to the left part of the screen
- esc: pop another roxterm, focus it
- ctrl-f9: resize it to the right vertical slice of the screen
- f4: switch to the browser desktop
- f12: put by browser in full screen, to check some reference without distraction
- f5: switch back to the terminals desktop
- alt-tab: switch to the roxterm that's currently on the right
- f12: make this roxterm full screen to do something without distraction for a while
- f12: demaximize and put back this roxterm where it was
- f9: now move this roxterm to the left, over the other one
- alt-tab: move to the other roxterm that was on the left
- ctrl-f9: put this roxterm in the vertical slice position on the right
- ctrl-space: make this roxterm sticky, showing on all desktop
- f4: move back to the internet desktop to check more documentation
- f9: resize the browser to be on the left part of the screen, so that I can see both the browser and the roxterm
- f5: move back to the terminal desktop. The space occupied by the browser will be replaced by the roxterm I left there, on the left
- alt-tab: move focus to this roxterm
- ctrl-t: open a new tab in this roxterm
- ctrl-v : paste some stuff from the internet browser
(etc..)
I have accomplished all that with about 20 keystrokes, from muscle memory. When I connect my extra wide screen, f10 and f11 have similar windows resizing function as f9 do on the laptop screen. f1 to f8 take me to desktop dedicated to some use or another (f7 is the windows desktop, with visual studio, f6 is the rstudio desktop, etc)
One think I positively hated until recently: copy and paste. Muscle memory means ctrl-shift-c in one application and ctrl-c in another didn't work. So in the terminal, I remapped the sigint signals to ctrl-x with stty. Hitting ctrl-x is just as convenient as ctrl-c and now I can copy paste as needed. ctrl-v to enter verbatim sequences is done with ctrl-q, just like in vim. so ctrl-c and ctrl-v work everywhere.
When I catch myself wanting to use the x copy paste buffer, the middle click is not so hard: on a thinkpad keyboard, it is right below the space key. But I just prefer ctrl-v. The luxury of having 2 independant copy-paste buffers is appreciable for some tasks however :)
Anyway, sorry for the long reply. I just don't have a lot of opportunities to talk about my setup. I am some kind of an optimization freak, I know it. But I don't want an interface to bother me. I have been using that for the last 3 or 4 years after giving up on OSX, and it has one great quality: I don't have to think about it. It just work the way I want. YMMV of course.
I use Openbox with some keybindings I picked up from ArchBang a while back, documented here [1].
tmux really comes into its own when you combine it with Vim and FZF [2]. I was initially hesitant to try tmux, but once I themed my tmux.conf and nailed down the keybindings, it became indispensable to me. I now use tmux as a basic organizational tool, and I always have at least one tmux session running on my desktop.
I have Ctrl+A+S bound to split the tmux screen horizontally, and Ctrl+A+A to toggle maximizing the tmux pane. Shift-DownArrow opens up a new tmux window to the right of the current one. Shift-LeftArrow and Shift-RightArrow move left and right between the tmux windows. I wanted it to be reminiscent of URxvt tabs.
Another one of my favorite bindings works as follows: visually highlight a line in Vim, then hit <leader>tj, which sends the highlighted line of code to an open terminal in a split tmux window below. Very useful for REPLs. You can also open Vim in the lower split terminal and use the same keybinding to send text directly from one Vim instance to another. It uses vim-tbone [3] and some custom bindings from @junegunn.
Very interesting. I love vim, and find the screen/vim mix a little unpleasant. A few years ago I looked at tmux and concluded I did't really need it because screen already did everything I needed.
Can you tell me more about that? The only thing I hate with gnu screen is the space wasted on the bottom bar, and the need to have commands in backticks otherwise
Would yo suggest some good resource to theme tmux?
(I use the thinkpad dedicated previous and next button, right above the left and right arrow keys to move between tabs in all tabbed applications. A pleasure to use. With shift, then change me to the previous/next desktop. With control, they move the currently focused window to the previous or next desktop, and change focus to that desktop too)
> I see you seem to be passing some info from vim to tmux right bottom bar, the utf8 the encoding. In vim, I usually show my offset in the file there.
The bottom bar is rendered by Vim with lightline [1]. The top bar is my tmux statusline, which I created by lightly customizing the output of tmuxline.vim [2].
I made my tmux.conf by customizing what I found on github, in particular @junegunn's dotfiles [3].
Not ideal, but the best solution I've found so far for moving text between the command line and other applications in urxvt is setting Bash to vi mode and then using visual mode for yanking/putting. I have Vim as my $EDITOR, which is opened when entering visual mode (I believe opening the editor is default Bash behavior). Vim is set to use the system clipboard ("set clipboard=unnamedplus" in the .vimrc) so from there I can bus text to/from other applications.
Then remap copy to ctrl-c, and paste to ctrl-v, and ctrl-x will work like your old ctrl-c, while ctrl-q will work like your old ctrl-v. remapping is easy with roxterm. I suppose xterm and urxvt can do the same.
If you like to remove part of words in bash, the following can be helpful too:
"\C-s": backward-kill-word
"\C-g": kill-word
"\C-w": unix-word-rubout
Kill word vs word-rubout is a matter of taste, and which separators are in your filenames.
I use awesome wm, tmux and vim. awesome gets the job done. I don't see differences enough in the others to make me go through the trouble of switching. I'm not super fond of the default keybindings but I know the ones I need - easy to re-bind but not worth it.
I use mostly the stock awesomewm taskbar/dock setup. I tried doing custom stuff there and it was doable ... but the "reload my wm and see if it fails to start even though syntax check passed" got old, and I gave up.
I'll usually have my desktop split two thirds terminal, with the remaining third split between browser[1] and slack. (Or all terminal, with the other stuff on additional monitor(s)). I don't usually have enough windows open to use more than one 'tag' or desktop, but when I find myself wandering afield in my browsing, I tends to shunt offtopic stuff off to another tag.
I use two tmux sessions , with one showing at any one time. I run them in Konsole - out of all the terminal emulators I've found, that's the one that can handle massive scroll rates without lagging.
The first tmux session is named 'pairing' and is where I do my day-to-day work. Anyone on my team who sshs in will auto-connect to that session. For a while I had it prompting me for approval via an awesome popup but that broke with the ugprade to more recent versions and wasn't useful enough to fix. I now just have a notification that displays on connect/disconnect.
Within each session, I have topical windows - usually per-project. A single vim and one or more shell panes. I have set up (neo)vim so that any time I "vi" in any pane of a tmux window, it opens in that window's vi session. A given window may have quite a number of shell panes depending on the environment. And for some testing cases, tmux's "synchronize-window" is invaluable.
In vim, I prefer splits to tabs and end up using lots of both. I'm slowly learning to get comfortable with buffers and will see how that changes things.
In the second named session ('private') I manage mail (mutt, but experimenting with more CLI-driven options like nmh), twitter (rainbowstream), irssi (via nested tmux on a cheap vps) and my project/notes/todo manager - which is another three-pane vim split, with shell functions that let me send stuff over there/read from there from anywhere.
I rely heavily on small helper scripts and lately a growing number of custom macros on my keyboard.
Some of the things I've read in the comments here have given me plenty more stuff to explore :)
Heh. Now that I write it up, I see that it's apparently really complex - but it's evolved over time and suits my work really well. I'm still ironing out the info/todo management tooling but it looks promising.
[1] If browsing text wasn't a horrible experience I'd do all of that in the shell too.
Edit: If folks are remotely interested, I can write up a blog post and publish some of my hacks.
I recommend the book: Tmux--Productive Mouse-Free Developmenet, written by Brian P. Hogan. It's a concise and practical book about Tmux. There are some usable configuration in it, and you can learn something about concepts like session, window, pane in the book. After you combine vim style with tmux, it's quite perfect to do anything in the terminal. Haha, enjoy!
This is actually why I prefer Emacs. I can literally do all my development work in Emacs, with a full-featured shell (e-shell), directory explorer (dir-ed), REPL and full IDE for Clojure (CIDER). It's pretty great.
TRAMP really has changed the way I look at managing remote machines. Learning to set the remote path somewhat sanely has almost completely eliminated my usage of regular terminals.
I do wish it was a little better on latency sometimes. But overall this environment is ridiculously nice.
My experience wasn't so simple. Griefs: coloring, git support problems, bash aliases. I'm sure there's a way to get it to work, but I wouldn't call it a full featured shell out-of-the-box; at least, it doesn't really compare with Terminal.
For git I use Magit, I don't have any bash aliases, and anything I would normally see coloring in when using bash in a real terminal has a full-fledged Emacs analog.
I use it (and created it) so I could use ansi-term instead of e-shell. Then C-c C-j lets you treat the term like a normal buffer (move, yank, etc), and C-c C-k when you are done lets you switch back to normal term style buffer.
I've found that emacs mostly eliminates the need for a shell. Most of what I was doing can be handled by Magit, Dired, and Async shell commands. The only thing I really use the shell for these days in long running npm jobs.
When I was first introduced to tmux, I was really excited by having a terminal session I could reattach to. I was never able to get very deep into it though: (1) a lot of the time a single script would get me up to speed, (2) the extra layer of abstraction broke some stuff I was doing, and (3) I couldn't make heads or tails of a lot of the tmux documentation. I'll definitely take a second look at a lot of the things people are posting here, but in the meantime, is there somewhere I can actually learn how to use tmux properly?
When I set up a new server, I always configure ~/.bash_profile as follows:
if [ $TERM = "xterm" ]; then
( (tmux has-session -t remote && \
tmux attach-session -t remote) || \
(tmux new-session -s remote) ) && exit 0
echo "tmux failed to start"
fi
if [ $TERM = "screen" ]; then
clear
cat /etc/motd
fi
This way tmux gets executed serverside always when I login remotely (e.g. via PuTTY), so my logon session and all running programs are always protected against sudden connectivity breaks. Also I rebind Ctrl+B to Ctrl+A via ~/.tmux.conf.
Three keyboard combinations to remember for beginner: Ctrl+A C creates a new window, Ctrl+A D detaches, and Ctrl+A {digit} switches windows. I'm not a power user of tmux, just a few basic features is all I need, but they have changed my server administration habits dramatically.
I've found that adding a simple configuration makes tmux a) nicer to look at b) somewhat more intuitive (the default colors made the screen confusing to me.)
With that and using tmuxp to manage a context for each of my projects, I can quickly "launch" a project and have a window with an editing pane, a pane to run tests and a pane to run deployment commands/anything else, all of the panes are already using the correct Python virtualenv, etc.
I think you should give the man page & built in documentation another chance. It's not that long (maybe 40-50 pages printed) and you can skip a few sections that you'll know to look up if you need them. You can also skip the detailed descriptions of most commands and options. Just having the important shortcuts memorized and having a general idea of what commands you have and what they do is all you need. Don't forget to read the examples.
One of the first things I had to with tmux is figure out a convenient prefix key. I found the default prefix key (C-b) to be a little clumsy to use. After a little experimentation, C-j has become my secondary tmux prefix key of choice.
It doesn't interfere with my shell or Vim usage. C-j is redundant in shell as well as Vim because it does what pressing the Enter key would do. Further, in Vim, C-j is synonymous to j in normal and visual modes. C-j is also very easy to type because my right forefinger always returns to j while resting.
This is what my ~/.tmux.conf looks like.
# Set C-j as secondary prefix key.
# C-b remains intact as primary prefix key.
set -g prefix2 C-j
bind-key C-j send-prefix -2
# Eliminate delay after <Esc> key press in Vim.
set -g escape-time 0
# Let Vim use 256 colors.
set -g default-terminal screen-256color
I've been using tmux heavily in my local development workflow for the last 6 months or so, and it absolutely pays off to have three window tiles in a single terminal window at a bare minimum. I am also using teamocil to manage windows and panes in tmux, although it's not needed at all: https://github.com/remiprev/teamocil
Either (v) for visual and the arrow keys, or (V) to select entire current line, then (y) to yank. (yy) will also yank lines without entering visual mode, which I use a lot.
If you're asking how I copy in general from stdout with the cursor, I select the text (selection appears yellow) and press Enter and it copies to the clipboard :)
"All problems in computer science can be solved by another level of indirection" David J. Wheeler
Tmux/Screen provides an extra redirectable abstraction layer over the terminal device.
The biggest complaint I regularly see about it is that people are used to the screen keybindings. I wonder why not add an abstraction layer there, where keypresses really call commands that perform the actions, and you could reconfigure these.
Tmux expects you to rebind its leader to Ctrl-a once you're ready to move off of screen. Otherwise, it's default works nicely if you are nesting screen inside of Tmux or vis-versa
I use Ctrl-a as the "go back to beginning of line" shortcut that Readline-capable programs offer by default [1]. That's actually one reason I never got used to Screen ;)
[1] that is, using the Emacs keybindings it exposes by default. I know you can change that through .inputrc
While it's better than the default terminal, iTerm2's tmux integration has always felt weak contrasted to the advantages of tmux.
I've used tmux for the past four years as my main environment, and was totally psyched to hear they were integrating it into iTerm2. But when I began digging into it, little from my workflows translated to the "integration" provided by iTerm2.
While it's a great feature of iTerm2, I find myself just using regular old tmux instead.
What features of the tmux integration do you utilize in iTerm2?
That's one frustration I have with Tmux. I want mouse scrollback, but don't want the other mouse controls. If I remember correctly I would accidentally go into copy-mode when I click-dragged my mouse by accident.
That's the largest gripe I've had. Eventually, I got used to not relying on GUI scrollback - that actually sped things up for me. In a pinch I just `hotkey, [` to activate scroll, then just use my mouse or page-up & page-down.
Even if you don't use tmux, get used to piping anything you'd want to read through `less`. It'll speed your workflow up.
I do use less sometimes, but sometimes I want to double check a command I typed a shirt while ago, or a command ends up outputting slightly more than I expected.
What I really want us an intelligent terminal, which attaches programming output to the program which produced it, let's me fold up long outputs, easily escape a long running program and store it output in a buffer for later checking, etc. But that seems annoyingly impossible.
iTerm's killer feature for me is the special paste modes - it is trivially easy to do things like visually select a block of processes numbers from ps and then paste that block as a space-delimited list on one line to kill them, etc. Terminal.app is fine for most things but can't do stuff like this.
On most of my systems, I tend to make a shell script out of it and usually save it to /usr/local/bin/kll (and I don't care about grepping out grep because it doesn't seem to affect anything).
killall and pkill don't work if the thing I'm trying to grep for isn't the first word of the process string.
Let's say I'm trying to kill 'python foobar.py' but I don't want to kill 'python bazquux.py'. The only thing it'll respond to with killall is 'killall python', but then both of them will respond. So I have to grep out the parameter and then kill that, with: ps -ef | grep 'foobar.py' | awk '{print "kill -9 " $2}' | sh
The one issue I have with tmux, versus using iterm natively, is that every single time I have to reboot my machine for an operating system upgrade, I lose all the terminal history of my tmux sessions - whereas with iterm, when the machine restarts, it restarts with the all the windows and terminal histories intact.
Its ironic that tmux doesn't provide any mechanism to save your terminal history between reboots. Tools like tmuxinator/tmux-resurrect will save your session/window/pane configs, but you lose all your history...
If I could just recover my (typically very valuable) terminal history between reboots, tmux would be the perfect tool for managing my terminal environments...
The history I'm referring to is the scrollback buffer. The work that I do, which is predominantly interactive in a REPL like environment with remote devices, has a rich history of information in each window/pane. I dread losing those scrollback buffers every time I have to restart tmux.
that said, i do mix screen on the local machine and tmux on the remote machine. lazy, but does the trick. of course one can script either to do everything one needs.
As an unsophisticated screen user without any interest in what seems to be a turf war, what is the deal with the never ending stream of "Use tmux!" articles on here?
I came from screen when I started using tmux. I spend quite some time to make the key bindings similar to screen, however, kept some things the tmux way because it was better. For people interested, this is my complete tmux.conf:
I do a lot of work in ssh shells, and somehow years ago I got out of the habit of using screen or tmux. I just took 20 minutes to go through the tutorial linked in this article.
With a pane open as a shell and another pane opened with emacs+intero almost immediately it felt better than using different ssh shells, which is what I usually do. The control-b prefix character use never interfered with any of my activities.
I've been a GNU Screen user for a good while. The increased productivity is wonderful.
However, I'm prevented from switching to Tmux because you can't attach to the same session from multiple terminals, and show a different window in each terminal.
I use this all the time in Screen - in Tmux, changing the window being viewed in one terminal, changes all other terminals attached to that session.
How do you deal with :terminal replacing your current buffer (it close it when you exit the shell). And the fact that as far as I can tell none of your keybindings work when you're inside :terminal?
Here's my terminal mappings: https://github.com/hhsnopek/dotfiles/blob/master/.nvimrc#L93
Otherwise I use neovim-remote (https://github.com/mhinz/neovim-remote), which will soon be natively in neovim, but until then you can connect to your vim instance and either create a new buffer or replace the existing one. You perform your things and then use `:w | bp` and jump back a buffer if you created a new one.
Similarly my keybindings can be mapped just as I did in my dotfiles (first link). Probably my favorite part is being able to search my terminal instance in vim style with `/` and navigate as I would in any other file
I started writing a terminal multiplexer in Rust, partially because I wanted to fix clearing ANSI escape codes to EOL, but also because I wanted to try and come up with a multiplexer that had very similar shortcuts and commands to Vim.
Hmmm. I had no idea there was powerline for tmux (I used powerline a couple of times in vim, then lost patience with it because sometimes I'd lose the wedges for some reason. It was early days then).
I prefer opening tabs in my terminal window instead of this or other similar tools. It's not an exact replacement but I try to avoid learning and remembering new sets of keystrokes, and there are some other small UI wins in my opinion.
I agree with you. I like that I can rip off terminal tabs and move them around. Also move them to different virtual desktops. I tend to have a virtual desktop for each project I work on keeping things spatially separate that way. One piece of functionality missing form this setup is the "pre configured scripted dev environments" but i've used this tool
It's definitely a cool tool if most of your development uses the command line. As a mobile developer, however, most of my development is spent in IDEs. Alas, that means my use of tmux is limited.
not sure he says screen is better. screen is much older, but it's interesting to see the code comparison. i doubt this says anything about code quality - i expect a lot of non OOP code in screen and more in tmux.
despite having fewer lines of code, screen's tar gz is at ~1mb, while tmux is at ~470k.
There is a bit more code in tmux but it's split in many more files than in screen, and there are significantly more blank lines and comments. tmux seems better in my opinion, but it's certainly difficult to tell without looking at the actual code.
