Yesterday I was helping a friend setting a box with no graphical session: I fired up tmux in the linux virtual terminal and then proceeded to realize without my tmux.conf I couldn't do a thing because I have always been using entirely different keybindings from the default.
This is the problem with too much customization. Learning to use the default configuration may be difficult but it's probably worth the effort, for vim it has definitely been in my experience.
I once lost my emacs dotfile and suddenly i was almost unable to use Emacs on my own pc.
Since then, i've decided to apply as little customisation as possible to software I use, and read the documentation and learn the standard configuration instead.
For some reasons nowadays it's trendy to add colors, bells and whistles to things but I've found out that learning the standard/default configuration lets me be instantly capable of intervention on whatever machine i put my hands on. Worst case scenario, i can tell programs to ignore configuration files.
Regardless of the frequency of such a situation, it can really bite you when something big breaks and you need to ssh into a vanilla server in the middle of the night under pressure. Trying to fix a production fire under the gaze of an angry CEO is stressful enough, but not being able to take care of business on a box because of a missing personal config is truly one of the worst experiences I've ever had in this business.
It's only happened to me once, but that one experience made me take a really hard look at my workflow, and years later, I have no regrets about scaling back my configs. I guess it really just depends on your job and on-call/firefighting responsibilities.
Keep your dot files in github. Grab them. No internet, I bet you have them on your laptop that you are ssh'd to the server from. SCP them over. Heck, cut and paste them if needed. If things are so bad nether of these work you have bigger issues and need to consider a design with some redundancy. Clos fabrics and VM/containers and if you have to have bare metal then you should have more then one (cluster or behind a SLB).
There is no excuse for a single point of failure in 2017. Not trying to sound like an ass but....
You did say it was years ago, so what I said seems to be true for today, no judgment on your situation years ago. My first major shit, got to fix it was on Solaris 2.51 so that shows my age.
I bind bash and tmux to vim keymaps. If that is not on the box it is the first thing I fix. I will be fast to resolve the issue if my fingers just work as I have trained them :)
Yep, I don't understand why people think you can't clone your dotfiles and copy over your ~/.tmux.conf to your home directory on the server. It's the first thing I do when I get an account set up, along with the ~/.zshrc and ~/.vimrc, and I have it all automated as a script. Makes everything easy.
Why? This lets admins log in as themselves (leaving an auditable trail) with access to their own dotfiles to debug and analyze on the fly. Even with ex. Ansible for managing and ex. Nagios for monitoring, being able to use a shell to diagnose and fix novel issues is invaluble. If you've got a better solution, please do share. (Sincerely: if you can make my job easier, I'm happy to listen)
Using Emacs config files as an example, what's the issue with storing config files on a server? Even if it's a 'production' server it's not like they contain much in the way of sensitive information. Does it matter if others have access to a list of keybindings, aliases, colour schemes, plugins, etc...?
What if their contracts with their customers state everything that deployed is from an audited source in order to leave no loopholes in the event of a data breach?
And if there is a serious data breach you better be able to prove that you never installed anything malicious or dodgy on there.
> What if their contracts with their customers state everything that deployed is from an audited source in order to leave no loopholes in the event of a data breach?
Just delete the configs after you're done?
I place all my dotfiles in a directory, usually in ~/mgmnt/. Then I have a little shell script, which backs up all the dotfiles I need found in ~/ and symlinks the ones from the directory. It's .zshrc, .bashrc, .tmux.conf, .gitconfig, .emacs.d, and probably a couple of other config files. I only needed to do this a couple of times, but reverting such "installation" is as easy as a couple of rm/mv commands so I didn't even feel the need to write a script for this.
This works fine if your configuration contains nothing too custom. Typically after copying my dotfiles I have to edit them quite substantially to make them actually work - mainly because they rely on outside sources (in .tmux.conf, stuff like `set-option -g default-command "reattach-to-user-namespace -l bash"`, in .vimrc it's usually colours, clipboard hacks etc that break). Maybe I should have a second, trimmed down version with no outside dependencies.
For some of these files you can add logic to check for the system it is on. For example (on iPad, do not have the files to look at now..will try to post later) my bash and tmux configuration check to see if:
Linux or OS X (for terminal setting)
If I am in tmux session already.
Check out https://github.com/thoughtbot/rcm. It has a hook system, so you can have it automatically run commands to install external dependencies – stuff like vim or Emacs plugins.
I manage hundreds of servers that are not connected to the Internet, to which I cannot connect any device without management approval, and which are redundant, but which are periodically reflashed and/or replaced with a whole new set with a 'clean' image, less dotfiles.
I keep my dotfiles short and sweet, because it's tedious to retype and I need the defaults to still be instinctive when I lose them.
In the "immutable architecture" style, the only time you see a shell on a production box should be when it's on fire (and even then, only if you need to do some "perimortem" debugging because the problem keeps reoccurring even when you just blow the server's state away with a reboot, and nothing in the "postmortem" logs tell you enough to diagnose or even know what more logging you should add.)
I'd hope an immutable architecture wouldn't break inside the box, since that would indicate it mutated :) And if it did, you'd just blow it away and replace it.
At that level, it's the interactions with different components that can break down, and the tools you use are more about testing configured interactions. Also, bad data. That bit necessarily mutates.
I'm a big fan of developing in a similar environment to production, so that the debugging tools and interaction are familiar long before an emergency. At our company, we develop on Linux and deploy on Linux.
I now use https://github.com/junegunn/vim-plug - you can setup a one-liner in your Vimrc to download and set it up, then :PlugInstall and you're done (similar to what they have in the readme but I linked to a specific hash on GitHub instead of master).
I also keep a separate file that lists the plugins to install and the source that from my main .vimrc. A lot of my coworkers have wanted my main vimrc for an "out of the box setup" of Vim and found it best for them to specify their own plugins rather than just blindly use mine - it also makes it easier for them to grab the latest copy without any conflicts.
Can you explain further what you want to do? But for me, I keep a github repo with my vimrc (among other configs) and I have a Makefile there that symlinks the repo files to ~/
Totally agree. I think a lot of the replies miss the point - that having non-standard configuration is inherently more complex, because it adds a layer of abstraction. It is simpler to not have this layer.
Related note, check out fish shell [1], whose design document has an interesting argument against configurability in software.
"having non-standard configuration is inherently more complex"
I disagree. It can be more complex, but it is not at all inherent. If I configure my shell, my editor, my whatever software to work more like other software I use (keybindings, etc), I can actually make it less complex for me, because copying over a few config files on those rare occassions I need to is much faster than trying to learn a whole new set of keybindings/behaviors (and trying to keep all of the different ones in my head).
Yes it is possible to tinker yourself into oblivion (especially if you change the same items frequently, and never come to a stable state), but that is by no means the inevitible outcome.
I also very much disagree with this line from the fish shell design page:
"Every configuration option in a program is a place where the program is too stupid to figure out for itself what the user really wants, and should be considered a failure of both the program and the programmer who implemented it."
Now I understand what they are getting at, and if they didn't start that sentence with "Every" I would not disagree so much. Yes your program should make it as easy as possible for you to figure out how to do what you want to do. However, not everyone in this world is the same. People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive. So every configuration option is most definitly NOT a failure of the program and the programmer who implemented it.
Granted there are programs out there that were seemingly made to purposefully obfuscate how they work (like the dev who wrote them gets some kind of sick pleasure out of making users' lives difficult :-D ). Obviously you should do your best to avoid that outcome (which almost aways comes not out of programmer malice, but other factors, I'm sure).
There is a place, I think, for a really good set of defaults that are consistent and easy for users to follow. I do not agree, however, that it must come at the price of forbidding users to customize their software. Tuck those customization options away if you must (if your philosophy is to encourage the use of the defaults), but I think it is a mistake to forbid user customization. If someone finds your program useful enough to want to customize it to their tastes, you risk losing a valuable customer/user who will move on to something that lets them shape it to work they want it to.
[edited to remove unintentional indent -- can't seem to break that habit of putting spaces at the beginning of the first line of a paragraph :D ]
> People have different preferences on how things work, and some of the choices on how to do things are mutually exculsive.
Yes! But asking the user to manually configure the system is a lame way to accomodate those preferences. It's better if the software can learn from the user. For example, if the user runs a certain command frequently, don't wait for the user to define an alias, just suggest it while the user types. Your shell can become more customized to you, with no configuration necessary.
This doesn't work for everything - key bindings for example. But it captures the "no configuration" world view.
> Tuck those customization options away if you must (if your philosophy is to encourage the use of the defaults), but I think it is a mistake to forbid user customization.
Not all configuration options are there to enable user customization. A lot of configuration is just punts on hard problems or decisions. For example, options like zsh's RC_QUOTES or bash's histappend. These don't reflect user preferences. They're just legacy or churn. The shell should just define its own language, and not make the user decide how '' is interpreted.
Every configuration point incurs a cost. The user who moved on to the über-flexible system discovered which plug-ins require which options, and which combinations are incompatible with each other.
This is where a layered approach really shines: have a rigid core with a flexible exterior. Allow the user to set the prompt, colors, key bindings, wrap commands likeΩ `grep` and `ls` to set colors, etc. Prefer open-ended customization (let the user write the function) instead of enumerated configuration (pick from N behaviors), an keep the core consistent so that there's something stable to build on. That's fish's philosophy.
Fair enough. I'm all for having the program do some intelligent prompting of the user, as long as it doesn't become annoying (like Microsoft's "Clippy" :-D).
There is a sweet spot with most software between being buried in a sea of options and having no options you can configure at all. I tend to gravitate toward having a sensible set of defaults and letting the user configure them otherwise if they want. Having options grouped together can be good too (like keybindings -- vim vs emacs style bindings for example).
I also like the idea of customization through functions/scripting rather than just giving the user a choice between N options. That's another area where a set of sensible defaults can be good -- defaults in that case, which can be programmed around.
BTW, thanks for responding here. Always nice to get feedback from the developers of a piece of software directly. I really haven't looked at fish for years (though I'm certain I checked it out a while back). I'll give it another look to see if there's something there to catch my interest.
Sorry I didn't see your response until today, I was busy the last couple of days and just got back to it.
I appreciate that you call out keybindings as a likely exception, but particularly in the shell, keybindings are 90% of my configuration! For some settings I'm sure there are sane defaults, but if programs don't know whether I prefer vim or emacs then they're going to have a bad time.
I did something different; I built my own config system that makes a PC account my own in about 20 minutes. My setup is effectively a program that needs to be installed, and I maintain it in a git repo, and it comes packaged with an installer. I'm a software engineer; I build tools to solve problems.
Emacs in particular is almost useless out of the box. But that's because of packages and modes; not because of key bindings and tweaks.
That being said, if a tool doesn't need extensive customization or doesn't ship with a broken config, I'll learn the defaults. I barely tweaked tmux.conf - I turned on xterm-keys and set-titles. And I've certainly reduced the depth of my configuration as the breadth of tools I use has increased.
And that's key: if most of my time is spent on one or two tools, it's well worth my time customizing those tools, because even fractional improvements will accumulate.
Well with Emacs it's more than customisation for me. I write my scripts and programs in Elisp, and if I don't do that, there's no sense in using Emacs for me, as I use it as my "computing environment". Plain emacs might be hard to use for a customising user, but I don't value that sort of use anyways.
Now it is superceded by avy (by abo-abo on GitHub) in every way + new features.
For such packages that always have room for improvement and not related to core emacs functionality, it is better that they stay in external repositories on GNU Elpa or Melpa.
That way, older packages do not have to get tied with emacs core. Currently Ido package is in that situation. I used to use Ido, but now I use the ivy package instead. Some people prefer to use helm instead. I would not be affected at all if Ido was removed from the emacs core in future and moved to GNU Elpa.
The thing about tmux bindings is that, as far as I know, very few people like the defaults.
I've taken the approach of 'learn the defaults' for vim, but on tmux that simply won't stand because the defaults have so much room for improvement.
Pretty much everything I've read on tmux suggests the - and | bindings for window splits, same goes for hjkl bindings for movement. Adding these bindings would go a long way towards standardizing tmux.
I use screen, and in my book the choice of ^A for the default escape is a giant WTF, and remapping that is the first thing I do on a new account before starting to use screen (I use ^o, for no particular reason I suppose except it's not used by anything else I use). Don't the screen developers ever need to go to the beginning of a line in the shell or editor?
This is really easy to remedy: just bind send-prefix to C-a C-a. That way you'll be able to easily go to line beginning inside tmux, and outside you won't type the unnecessary 'a' character.
Moreover, I forgot if it's the default or if I set it somehow, but in Emacs a single C-a goes back to the beginning of a line, but C-a C-a goes back to the beginning of text on the line, which is almost always what I want anyway. So I press C-a twice anyway, everywhere, and I don't have the problem you described at all :)
At this point it's muscle memory for me to use C-a a to get to the beginning of a line, to the point that when I'm not in screen there will be extra "a"s at the beginning of my commands.
As for editors, I use vim. (With almost no customization, as others have advocated.)
A friend suggested remapping the Screen command key to ` (backquote), and it changed my life. Maybe it's because I grew up using Esc key combos a lot (terminals with broken/missing meta keys), but it feels natural to treat it like another modifier key there on the left edge of the keyboard.
I did that as well, and it was Great and Good and obviously the Right Thing — right up until I pasted in a some shell code which used `` instead of $(). Never again.
These days I use C-z for tmux. It works, and C-z z is easy enough to type when I want to put something in the background.
I'm a committed (interpret that as you like) tcsh user, so yeah, that keybinding gets in the way. On the flip side, it's gotten me out of the habit of blindly copying/pasting shell code, which is a security win, right? ;)
I just switched from C-z to C-q and couldn't be happier. C-z was fine, but I realized it was a really unergonomic stretch. With caps lock as ctrl, C-q is only a slight movement of my ring finger.
Well, I think a lot of it is because not everyone has historically had emacs mode defaulted in their shell. Lots of people who learned to use the shell in ksh (myself included) probably share similar feelings towards the emacs bindings. With that in mind, ctrl-a makes a lot of sense when you're not in emacs mode. `set -o vi` is a wonderful command ;).
I never used screen and still did the rebind simply for the easy 1-handed operation. I ignored the prefix change because I've actually hear some people prefer the default ^B. I know of no-one who prefers % and " for pane splits.
That, and switching to the vi-like keybindings for copy mode, are the only two things I change. And even so, I can and do use an unconfigured tmux with only minor irritation. Configuration just looks like an elaborate way to make sure you're unable to use other people's systems.
It gets worse when you work in ops and are constantly needing to remote into servers and you regularly have tmux within a tmux within a tmux... Littering config files across the datacenter just isn't an option.
> Littering config files across the datacenter just isn't an option.
Er, what about an LDAP server for user profiles and an NFS server for home directories, like the university timesharing clusters of olde? Any box you'd log into would have "your config files" (in fact, your whole home directory) on it.
NFS is a nightmare, for many reasons. But there are similar solutions such as `pam_mkhomedir` which can be coerced into fetching dotfiles when a user logs in, etc.
Could you please share some of those reasons? I ask because I'm doing this... hasn't been a problem yet, but I'd rather know about issues now than later!
NFS can frequently cause hanging guests if the server goes away, leaving the filesystem mounted.
Locking is often a problem, for example if you've got ~ mounted on NFS and you're delivering mail to mboxes - obviously maildirs sidestep that particular problem.
Firewalling is a real pain, as is access-control and UID remapping. (These are more concerns when you have a single server sharing a tree to multiple clients.)
Finally failover & high-availablity are hard because you can't do transitions terribly easily, although hacks exist using automounter, etc.
You can make use of your configuration management for this. If you use something like Chef or Puppet, you probably have user accounts being created on servers when they are provisioned. We have user configs, like bashrc, tmux.conf, vimrc and all that stored in Puppet so they have those files on every single server. It all goes through code review so we can always see if something is overreaching or dangerous.
If you are creating user accounts on servers by hand in a datacenter, then when that person quits... well, you have other problems I guess.
Exactly. There's such a great difference between Emacs with half a million of lines of Elisp loaded and a vanilla version that it's easier for me to just use Vim (it's everywhere anyway, but I can work with Vi too).
Using vanilla Emacs is like writing a GUI application with nothing but the primitive X (or GDI) operations. The potential is there and is visible, and it's sometimes the right thing to do, but normally you'd use GTK or QT, right? Same is true with Emacs: in its vanilla form, it's just an API for text editing with a bunch of outdated defaults. It's superb as a platform for writing text-editing related (and sometimes others) applications in Elisp. I think that Emacs is not supposed to be used in that state at all, even. Vim, on the other hand, is pretty much designed around one UI & text-editing philosophy, which makes it less extensible, but much more usable out of the box.
Edit: mg is an emacs-like editor that is even leaner than vi, has off course the same key bindings as emacs, and also shares the same openbsd roots as tmux. It is also the default editor in openbsd.
Yeah, this is a good approach. I have memorized how to set up three settings for vim I just have to have, but I can usually do that in less than a minute.
For many people, line numbers are the first thing they set up - I never understood that. I customize vim quite heavily, and have tried showing line numbers, but all they do is take up 4-5 characters of precious window width! I can see the current line in bottom right, and when I want to go to a line, I use `45gg`.
I've never really gotten into absolute line numbers, but relative ones are a godsend for me since I use <num>j, <num>d, et al a lot but can't really eyeball how many lines away something is once it gets to be more than 2 or 3.
I do 90% ops stuff and never have this issue with tmux, so I'm curious what your workflow's like. Why not just have tmux running on your host machine and ssh from a tmux window?
Fair enough. My personal workaround (though, hacky, I guess) is to use screen for preserving the shell. It has a slight advantage of being more accessible, since more people know screen than tmux.
Actually this benefits me, having identical settings in my nested session means typing :send-prefix all the time... remembering how to use tmux with default settings makes life easier.
You're not wrong about the problem, but there is an issue: sometimes the defaults are really, really bad — e.g. C-a as a prefix character, when anyone who uses emacs keybindings is used to that keystroke taking him to the beginning of the line.
The solution, of course, is to improve the defaults, but that's not always practically possible. Sometimes the maintainers refuse to do the right thing, and sometimes there is no right thing (e.g. should be use C-{b,f,p,n} or hlkj?).
I'd rather have a system which enables me to mold it to myself — even at the risk of being unable to use the same system configured differently — then have a system which forces me to do the wrong thing.
I agree a lot with this, for two reasons: the one you gave, and the fact that customizing too much your tools makes them unusable by anyone else.
I don't know about you, but at my work we're often working on someone else computer (debugging, pair programming...). Always keep the default config available!
Very good comment which applies to many console apps. I did this with Vim, the only custom key is 'jk' instead of <Esc>. But Vim has really good and sensible defaults. But tmux' % and " (for vertical and horizontal splits) are so counterintuitive, I kept them but still after many years, I still have to think a millisecond every time which of them to press and on top you need to press Shift as well which makes it even more cumbersome.
I have personally been running in to the problem of TOO many different ways to do the same thing. I am using many tools that all do a certain part better and each one of them share certain features which are accessed in all different ways (or it does something slightly different).
i.e. Atom, Emacs, Neovim, and PyCharm. I try to stick to one, but switch around to get the best of each of them. It's been driving me crazy lately thought.
Generally (especially with editors) I try out every new toy as it comes to my attention, but then go back home to vim and recreate whatever I liked, whether as configuration or with an extension. It helps that many of Atom's best features have inspired plugins :-)
Considering it takes one command to recover a tmux config file, I don't see the value in optimizing for the rare occasion where I won't have the config file already in the environment I'm working in. In fact, if I'm not able to use my config file, chances are, tmux is not available for me to use anyways.
This is more tmux' fault for having terrible default keybindings (and settings) and I'd rather not waste my time learning and configuring them. That's where byobu comes in.
This is my experience as well. In my larval hacker days in the '90s, when my primary pastime was messing around with my Linux box all day long, I thoroughly enjoyed sifting through window manager and shell man pages to find each and every thing that could be configured, and I'd then proceed to configure each and every one of them to exactly what I wanted. My fvwm/bash/etc. config files from those days could probably be considered a form of outsider art by someone.
A common pattern in mailing lists/forums/etc. is the "just make it an option" guy. People are talking about their wishlists for future versions of <Gimp/emacs/Xorg/LibreOffice/whatever>, and sometimes these wishlists conflict. One group says a UI should be one way, another group says it should be some other mutually exclusive way, and a third group thinks the developers should implement both and just make it an option in a dotfile to make everyone happy.
Sometimes "just make it an option" guy is right, but in hindsight it should never be the default resolution to the disagreement. In those days I defaulted to "just make it an option", and really internalized that philosophy because it felt like all benefit and no cost. Why wouldn't you make everyone happy, if you could do that instead of making one group happy at the expense of another group? I think it's a really common trap people fall into early on because they have yet to directly perceive the costs that that approach can incur over time in software development. Sometimes they've also tricked themselves into overvaluing their workflows and muscle memory, which they may have defined in part because it was easier for them to define their own keybindings than memorize what the default ones were, which I now think is an antipattern in itself.
The main thing that changed for me is spending the intervening decades doing work on multiple machines all the time, running different versions of different OSes, often times starting from fresh installs. That made it more pragmatic to always learn software in its default config, and only tweak configs if it's absolutely necessary or otherwise pretty important to me. It's also forced me to learn all sorts of useful stuff that I probably wouldn't have otherwise. It also drove home just how much my desire to tweak configs was just because it was fun for me (and I had lots more free time back then), rather than something that made me more effective as an engineer.
But that's just from a user perspective. From a developer perspective, having "just make it an option" be the default form of conflict resolution leads to all sorts of unanticipated complications in practice. Every time an alternative code path is added for something, the code becomes a teensy bit more fragile and likely accrues a teensy bit of technical debt. The fragility and technical debt accrues over the years, and eventually can turn even the best software into an unmaintainable mess. I'm not dogmatic about it- some things should be options. It's just never my default position, and I have a much higher bar nowadays for making something an option.
I agree completely, but like to think of it a little differently.
While it's easy enough to put your dotfiles on github, and pull them down onto every machine you touch, or possibly even automate that, it doesn't solve the fundamental problem that software that requires extensive customization is not good software.
If the right trade-offs haven't already been made in the default configuration, then it's an immature application waiting for a rewrite.
Put your dotfiles under version control. Open a repository for them on github. A complete personal install on a fresh box is just useradd and git clone away. Two commands to paradise.
Google dotfiles in git. It's easier than you think.
One of the things I stress in my book is that there is no "correct" way to use tmux. The approach I take to teaching tmux is separating it into its objects: The server, sessions, windows and panes. Then where they stand in relation to one another, how configurations work, and then leave some examples of usage available to the user so they can pick out work flows they may like.
I'm sort of against the approach of just throwing a config / toolkit at someone a la oh-my-zsh and spf13-vim (even though I think they're ok after you've learned to customize yourself). The gift of allowing someone to wrap their brain around something will let the rest come to them.
Out of curiosity: Why do you write a book and let it be read publicly if you sell it as well? Why should somebody buy a book when all the content is available for free? Is this done to create some awareness for the book and thus to improve SEO (e.g. generating good backlinks, etc.). And later you restrict the public available content once SEO backlink power is generated?
Our of curiosity 2: Are you happy with the sales, how many books could you sell already (if you don't mind to tell us)? Would you write again a book about a console-based app?
I basically use tmux as my window manager. I only typically open two programs: a browser, and a terminal. Both are always in full-screen mode.
It makes things nice and simple. No matter if I'm working on a laptop or a desktop, all my terminal windows end up in the same place and have the same settings. It's great!
They are not mutually exclusive. I use xmonad, tmux, and vim together. Tmux adds some niceties on top of xmonad like shared keybinds with vim making moving across vim panes and terminals seamless. Also, I can jump on my macbook and login to my desktop using mosh and re-attach to the tmux session and continue working where I left off.
Me too, and it's great and even works on Windows with Babun :-) If I use tmux as window manager, I don't have the problem with installing fluxbox etc. on Windows :-)
So this may mark me out as different, but apart from persistent remote connections, I've never really felt the need for screen/tmux.
I've been trying to figure out what the fuss is about, and I still really don't understand (apart from persistence and screen sharing.)
When I want multiple terminals, I just fire up another terminal window and hey presto, jobs a goodun. I have a fairly high res screen and small fonts, so I can fit many terminals on one screen. If I run out, I hop over to a new virtual screen.
Perhaps this is a by product of working in linux/unix so long? I can imagine that if I was forced to use putty, where connection setup is costly and screen space scarce, I'd want tmux to make things quicker.
Vim + tmux with custom bindings makes moving between vim and a terminal seamless. The same keystrokes for moving between panes in vim can be used to move to tmux panes. Also, as a vim user I loathe to reach for the mouse, so having quick and easy keybindings for launching and arranging tmux panes is great and preferred to the imperfect and slow arrangement using a mouse. Lastly, I can have tabs and window panes that are named and in consistent locations and persisted across sessions, so I can immediately jump around a dozen projects without much cognitive load. Try having 15 terminals open and remembering which is which and you'll find there is a high context switch cost, so you constantly have to close and open terminals. This isn't the case with tmux.
What happens when you're remoted into another box? Multiple terminals is fine on local, but when you've SSHed into some remote, screen is your friend for managing multiple parallel sessions of work. (In addition, as you mentiond, to persistent sessions -- if you break off, you can always reattach to any of your sessions)
Its just never really been a problem, ssh'ing into remote boxes has literally no cost (I have auto complete hostnames, and sshkey pairs.)
for processes taking longer than a day normally need something like screen, however thats so rare, most things are run inside another execution environment(jenkins, render manager, grid engine/mesos etc)
The remote server I happen to do most of my work on right now has tmux installed, so I don't even need to bother with screen anymore (at least for now).
The problem with opening multiple terminals is that you will eventually be slowed down in your workflow. Say you want to switch to a particular terminal, and you have more than 10 terminals running. You either have to press CTRL+Tab a few times (5 times on average for 10 terminals), or switch using the mouse, both of which are slow.
Another problem is working remotely. If you connect to a remote server, and you need another terminal for that remote server, you must establish another separate connection. With a terminal multiplexer, you do not need that.
I had this problem, although I found after I started using a tiling window manager that I gravitated back from screen (which I used obsessively) to workspaces with a fairly small (usually two, sometimes three) of xterms running. I might have a total of six running, but they're on three workspaces, and the workspaces are conceptually discreet.
Tab cycling through more than 3 terminals got to be very tedious, but it also often got to be more difficult with the multiplexer to remember the absolute ids of terminals (in cases where I was opening a bunch of them to debug a problem) than it was to visually spot the one I wanted when I had them grouped into workspaces whose ids have meaning to me.
The remote thing you mention definitely gets to be a nuisance; usually when I'm debugging a remote machine, I open an xmonad workspace and on it a couple of terminals. It feels chintzy to ssh twice, but it's also weird to go from one set of terminal selection commands (xmonad's) to another (tmux's).
Anyway this probably sounds like I'm disagreeing, I totally agree but the tiling WM's threw a wrench into my thinking about being able to absolutely select specific terminals.
I have a small screen with my laptop so I can only fit one terminal. It's pretty handy to change terminals all the time. Also it's handy to have all the terminals I was using popup again when I'm rebooting my computer (tmux-ressurection)
I have a heavily-tweaked Tmux that uses a lot of custom bindings but also incorporates Powerline to make the status bar helpful and homely. I spend so much time in the terminal and only Tmux can really personalize it. It looks good, and it feels like a good place to work. It's no big deal, having the time, date, current song, weather etc all there to see, but it is a pleasure to have.
A terminal that be made to feel like /home? Oh yes!
I use tmux constantly but I barely know three tmux commands. Get all the benefit with none of the cognitive overhead with `tmux -CC` in a supported terminal (like iTerm). It allows the GUI program to take charge of the windowing and paneling in its own native way. It's lovely.
It still sounds like a very shallow (naive?) use of tmux to me, I'm in no way a real power user of tmux and I use a lot more feature than that.
You could talk about binds without prefix, sessions, customized status bar, pane swapping, bind keys to script launching, plugins, pane highlighting...
And the best feature of all for me: maximized pane toggle. I use that ALL the time.
I never could find all features I needed from an emulator (plus, I want a drop-down terminal), Tmux have them all and more and I'm not dependent of a specific emulator.
Do you have any better recommendations on what to read in this case? If you do, I would love to read them! If not, you could do a great thing and use your knowledge to help the rest of us out.
Most people use tmux locally, because their terminal emulator doesn't do what they need it to do, or the window manager doesn't do it. Using tmux locally merely supplements the window manager. I stopped using tmux locally after switching to i3 (and I believe any other tiling / proper wm would do). Now my only use case for tmux is on the server where I'm running weechat. When sysadmining, it's eaiser for me launch few terminals in my window manager and ssh to the same server, then running tmux remotely. It's simply a question of ergonomics, how many sets of keyboard shortcuts do you need to remember to handle a multiplex... eh, window manager running inside a window manager?
But in all seriousness, I do sometimes find myself using tmux, but I try hard not to fragment myself over tools too much, especially with screen finally having vert split, and tmux being BSD, this is one of those cases where I think screen while it has some quirks and may have a bit of a learning curve is worth the effort.
edit: Since I didn't provide much value and my comment was a bit snarky, here is a truly useful tmux shortcuts and cheatsheet link:
There is one thing I want from my terminal multiplexer: working scroll functionality with Shift+PgUp/PgDn, even in split screens, just like in a plain console, without messing everything up. Is that possible?
Hey, I just tried that and it's pretty close to what I want. Thank you.
edit: close, but no cigar. It enters "scrollback mode", which you have to exit before you can type again. It's just like screen's copy mode with different key bindings.
I wrote my own terminal emulator and screen-like program to get there... I made mine send the code for shift+pageup/down when the application is in alternative screen mode, so I could forward the keypress all the way down to the server...
You do one better - tmux's mouse mode allows you to scroll with your mouse wheel.
Just add 'set -g mouse on' to your ~/.tmux.conf. You can configure the history size limit by setting 'set-option -g history-limit <lines>'. When you scroll the mouse wheel, tmux will enter copy mode and scroll.
The problem is, my terminal already has a concept of scrolling, and its own concept of a buffer, with its own concept of keeping unlimited contents based on available memory, etc.
I've never seen a tmux setup that doesn't fail horribly when these two concepts collide (I can't cmd-f search the buffer for interesting things, I don't get a scroll bar on the right that shows me how far up the buffer I am, scroll acceleration doesn't work, etc.)
Terminal.app already does split panes, tabs, scroll acceleration, search, etc. I don't get persistence, but I don't really understand the workflow where you'd want it. I typically open new tabs exactly because I want a fresh workspace, and I close them exactly because I want to clear my workspace. I can just manually call tmux when I know the thing I'm running should outlast a window (and actually, 99% of the time that's on a server I'm SSH'd into, not on my local machine.)
Can anyone convince me why I need to be all-tmux all-the-time?
>The problem is, my terminal already has a concept of scrolling, and its own concept of a buffer, with its own concept of keeping unlimited contents based on available memory, etc.
Perhaps try iTerm2 (for Mac) native tmux integration. You can have tmux panes and split panes that are (and behave like) regular terminal panes and tabs.
Sessions are the killer feature for me. I have a session for each project I work on and can have all my tabs, panes, vim, etc set up and switch between them at any time. Sessions can be persisted so that even if I reboot my machine all my project workspace configurations are saved and ready to go.
The session doesn't actually persist between boots. I think what the parent must be referring to is the ability to create tmux session configurations. Then after a reboot if you try to connect to the session which no longer exists the conf will spin it up for you.
I disable my Terminal.app buffer. If not in tmux, can't scroll back. All scrolling and copy and pasting is done with tmux. Also use vi keybindings so I select text and copy using same keys in vim and tmux.
I disagree. I want to select with the mouse and touch type with the keyboard.
And "doing it faster" is never a concern. As a programmer I write about 5% of what I could type in the same time as a secretary or accountant. Most of the work is thinking.
Plus, the occasional chance to get your hands off of the rigid (and carpal tunnel inducing) pose on the keyboard and move them to the mouse, or vice versa, is welcome.
I don't want to replicate things the mouse does better with keyboard shortcuts, or suffer "modal" input-modes in my programs.
I myself prefer to scroll with the keyboard in tmux, but for moving the cursor and selecting text, tmux has a very, very long way to go before being optimally efficient and useful in this regard.
The kings of keyboard-based cursor movement and text selection are vim and emacs, both of which have a very rich and powerful toolbox of techniques and plugins that help the user do that quickly and efficiently.
For example, emacs has plugins like ace-jump-mode which lets you jump the cursor to any precise position on the screen by typing just one or two keystrokes. vim has similar plugins, like easy-motion and precisejump.
vim and emacs also have quick ways to select words, sentences, paragraphs, functions, lines, logical and visual blocks, the entire document, etc. This includes having full access to rich and powerful regex text matching, which can be used for selection.
In contrast to emacs and vim, when I try to move my cursor and select text in tmux, I feel crippled. So sometimes I do succumb to the temptation of using the mouse to select text in tmux, despite being quite comfortable and satisfied in using the keyboard exclusively in vim and emacs.
Then I can just enter tmux's vi mode, and scroll up and down with shift-J/K. I don't know of a way to bind shift-PgUp/PgDn though, which sounds like what you are looking for.
I used to be an extensive user of tmux, basically I'd have a sprawling set of sessions, all backed up with the continuum and resurrection plugins. It allowed me to armory seemlessly work remote on my main dev box or through SSH. Of course the biggest pain was consolidating the X11 clipboard and tmux's internal one.
Since I switched to Emacs though I've gradually peeled away the tmux layer. I still run without X11 version of Emacs so I can remote in, but Emacs itself does an equal or better job at pane management and session persistence, especially using daemon mode. ANSI term inside Emacs, something that has really improved in the past few years, has cinched the deal for me. Tmux had become bloat at this point for me.
Funny, I'm going the other way. I used ansi-term (well, multiterm) with a daemon emacs for years, but in the end, a few things ended up being too much:
* some programs didn't render properly in ansi-term
* opening really large log files was dubious
* hanging a buffer by, say, accidentally running a long macro would wipe out all my terminal sessions and open files
* lingering suspicion that modal editing makes a lot of sense
These days I'm picking up tmux and kakoune and loving it. I guess everyone likes to change it up now and then. :)
After experimenting with mosh, tmux, screen, etc I've finally found my ideal ssh setup. At work I do development on my Mac and run builds on a cloud desktop. My Setup:
4. tmux -CC command to attach to tmux session with iTerm Tmux integration. This is the killer feature, it treats a tmux session as a native iTerm window. This means all of the 'learning' you previously had to do with Tmux is nearly non-existent (copy / paste, switching tabs, etc). My biggest annoyance with TMux was the copy / paste special handling. Huge productivity loss.
All-together it looks something like this:
Open iTerm.
autossh -t myRemoteHost "tmux -CC -A"
Instantly have a _fairly_ durable terminal session on my remote desktop.
I'd argue that using a terminal multiplexer like tmux or screen on a production server (as this article implied) often means you are doing things wrong.
It is better to set up a service (systemd or other) and configure it to start correctly rather than relying on a tmux session to manage long running processes. By going this route you get logging, auto restarting, starting on boot, monitoring etc for free.
There's difference to daemons and Kong running process. Long process might be tar up all these files, or copy all these. Things that takes 10 s of minutes to hours. Things you don't want to bomb out just cause network died. Things that are one off and variable enough it doesn't make sense to write a server for them.
And of course any you don't want to be interiors part way. Like upgrade or deployment
I love Tmux, I just can't seem to wrap my head on how to COPY and PASTE something lol. Anyone have any step, by step tutorial for how to copy and paste like VIM? I would like to be able to see what is being copied just like in VIM's visual mode. Like If I can copy some code in VIM and then go to paste in another REPL pane in TMUX then that would be my ideal goal!
This allows you to scroll up in the window and place the cursor where you want to start copying, then:
C-SPACE Set mark
This sets the mark for copying, then you can move around and what will be copied will be hilighted with a background color.
M-w Copy selection
This copies the selection. Incidentally, M stands for "meta" and is nearly always usable with ESC, but often ALT will work in many terminals (some need a setting to enable it).
To paste, go to the buffer you want to paste into and then:
Whatever TERM is set for you outside tmux needs to have a full ncurses terminfo with all the extended ncurses-specific codes. Assuming that screen and screen-256color on your system is similarly fully-featured with respect to ncurses, then you'll be in a good position. If you're lucky, TERM=screen-256color inside tmux and you're good to go.
Without that, there are a variety of hacks at different levels of the processing stack you can use to fix things. You could set TERM to screen.<your-terminal> if your system has the right settings for screen.<your-terminal>; or you could try setting it to <your-terminal> if <your-terminal> is sufficiently xterm-like.
You need to set your tmux.conf to use the correct term type. For modern distributions it should be
set -g default-terminal "tmux-256color"
You also need to make sure tmux understands that your terminal supports true color mode. Set the following if e.g. using gnome terminal (which calls itself xterm-256color in $TERM)
set-option -ga terminal-overrides ",256col:Tc"
You'll need to reset $TERM to something more standard if you plan to SSH to older systems, though. I have a shell function that wraps SSH and sets the term type to screen for when I log into old systems.
I use ... Screen on production servers. ... Screen has the lightest footprint
dtach, which is what I use on production servers even though it usually doesn't come standard, probably has the lightest footprint if you just want to return to some screen later. It doesn't maintain history, however, the screen is redrawn, if possible, on reattach.
Otherwise, yes. Both tmux and the book are great (if you don't mind getting drawn into wasting time on customizing the status bar and such).
I have my tmux/vim set up so that C-(h,j,k,l) navigates vim splits and tmux panes seamlessly. The only downside was that I had to rebind C-l to C-o to clear my shell. But it makes it a lot more productive when using multiple shell panes along with my vim session in one terminal window.
A big thing I've done is use my multiplexer segregate contexts. When I spin up screen (tmux would work the same, just never switched) I set an environment variable noting the particular context I'm working in, and I adjust my PATH, HISTFILE, and more based on this variable.
I create new sessions and name them appropriately. My one wish is to be able to do "PREFIX ls" and then just hit enter on the session to switch to. I may be missing something, but I always have to do "PREFIX a -t [session name]".
Great read - prompted me to actually learn tmux, has been worth it! Also thanks for the link to the book, I ended up buying https://pragprog.com/book/bhtmux2/tmux-2
There's subtile difference between terminal emulators (terminator) and terminal multiplexers (tmux, screen), mentioned elsewhere [0]. IMO the main difference: With tmux, your sessions can be separate from your terminal instance. Meaning that if your terminal dies for any reason (e.g. X dying), and you've set tmux up correctly, your session will still be there and all you have to do is (re)connect.
The other reasons are probably more personal. The initial tmux learning curve is steep, but once you've got it, it rewards you with a super fast workflow that suits you. I know this sounds extremely stupid, but the "hacker cred" is large with tmux. I got hooked on tmux by a coworker who used it and ruled. I've never seen that with terminator, although it should be equally possible.
Terminator is an alternative to something like iTerm. Tmux is server based so the sessions persist after disconnecting from ssh for example and allow multiple users to connect to the same terminal
I personally would, because learning less tools is great.
I've had some problem applying this principle when using tmux locally on a system with i3. You kinda need to be consistent in which of the 2 you use to create new shell windows.
Isn't the emacs philosophy to never leave emacs? Doesn't using tmux go against that? Or do you run tmux inside of emacs?
I use spacemacs and coming from vim, its taking some getting used to but I'm still always trying to do more things in emacs and not switch to my terminal workspace.
I feel spacemacs is just a vim clone with really bad cpu and ram utilization. If I am going that road, why not use an ide like eclipse or visual studio instead?
If chrome ran within tmux, that would totally be my approach. Sadly, there remain GUI's that are better than TUI's (or rather: sadly tmux can only multiplex TUIs).
My favorite tip: add bindings with the control key. So if you use "Ctrl-b n" to go to the next pane, add a binding for "Ctrl-b Ctrl-n". It's easier to keep the Ctrl key pressed than to lift it.
If that means in contrast to the default configuration, then probably yes. tmux default is not bad, but each person would probably do better with a few common adjustments, and maybe a bit more for their local needs and focus.
Does mouse copy and paste work correctly with tmux? I find that it selects spans across multiple panes. Is there a way to fix this or Windows or Linux?
I use the "PREFIX z" command to "maximize" the current pane, that is, it hides all the other panes and makes the current one the only visible pane, filling the whole terminal. Then I copy, and "PREFIX z" again to go back.
If you don't enable mouse support (set -g mouse on) then the terminal process handles mouse and does what you're describing* . When you enable mouse support tmux handles selections within panes and doesn't span.
* the other possibility also is that your term emulator is configured to grab mouse control without passing it through.
> advocates tmux but do not mention a single feature not on gnu screen.
why on earth would someone be that impractical?! just get a single gnu screenrc file that does all that and call it a day on every single environment you work on.
Honestly, tmux is not hard to use. It has some contorted key bindings, sure, but its benefits are so immediately huge that the motivation to learn its quirks is huge too. And, unlike say, vim, it only has 3 things you really need to know: panes, windows, detach. Most people who use tmux, even casually, will inevitably be using it 'properly', within a week, and fluidly within a month. So this blog post is quite redundant.
