Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using tmux properly

danielallendeutsch.com

Post reply on HN
Print view View original

121–130 of 218 posts

Re: Using tmux properly

#121

Post by git-pull »

I am author of The Tao of tmux, a book I just finished a few weeks ago. You can read it publicly at https://leanpub.com/the-tao-of-tmux/read.

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.

Re: Using tmux properly

#122

Post by teach »

ausjke wrote: post #119

I used the default all the time and it worked fine for me. by the way what is PREFIX meaning? ctrl-b?

Yes, CTRL-b is the default prefix. The default prefix in screen is CTRL-a, so a LOT of tmux users remap the prefix to match.

Also, CTRL-a is much easier to press, since B is a long way away.

tmux only uses CTRL-b so it won't conflict with screen's shortcut in case you find yourself in a screen session inside a tmux session.

Re: Using tmux properly

#123

Post by zachlatta »

Lxr wrote: post #116
myrandomcomment wrote: post #100

Earlier quoted context omitted.

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 S…

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…

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.

Re: Using tmux properly

#124

Post by derefr »

barrkel wrote: post #87
save_ferris wrote: post #76

Earlier quoted context omitted.

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 bus…

If the only time you see a production box is when it's on fire, I think there's an organizational problem. Occasionally acting as third-line support means real production disasters aren't an unfamiliar zone.

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.)

Re: Using tmux properly

#125

Post by derefr »

spacelizard wrote: post #49
rnhmjoj wrote: post #33

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, f…

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.

Or, if the LDAP part is a hassle, be a hipster and pull all the 'user profile' info from GitHub (https://github.com/tsutsu/github-auth3).

Re: Using tmux properly

#126

Post by pathompong »

nehcsivart wrote: post #95
KaiserPro wrote: post #75

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,…

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…

openssh supports connection multiplexing. But I still love tmux even on local machine.

Re: Using tmux properly

#127

Post by tacostakohashi »

mwfunk wrote: post #82
rnhmjoj wrote: post #33

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, f…

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…

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.

Re: Using tmux properly

#128

Post by rhinoceraptor »

elpocko wrote: post #17
rhinoceraptor wrote: post #8

Earlier quoted context omitted.

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 '. When you scroll the mouse wheel, tmux will enter copy mode and scroll.

That is absolutely not 'better', sorry. Taking your hands off the keyboard to do something basic is never better.

I can still navigate the scrollback in tmux with my keyboard, I just prefer not to.

Re: Using tmux properly

#129

Post by base698 »

teach wrote: post #122
ausjke wrote: post #119

I used the default all the time and it worked fine for me. by the way what is PREFIX meaning? ctrl-b?

Yes, CTRL-b is the default prefix. The default prefix in screen is CTRL-a, so a LOT of tmux users remap the prefix to match. Also, CTRL-a is much easier to press, since B is a long way away. tmux only uses CTRL-b so it won't conflict with screen's shortcut in case you find yourself in a screen session inside a tmux session.

I never understood that since ctrl+a jumps to beginning of line. Ctrl-o is what I use, but probably in the minority.

Re: Using tmux properly

#130

Post by CardenB »

MaikuMori wrote: post #65
znpy wrote: post #46

Earlier quoted context omitted.

I 120% agree. 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…

That's why I have public dotfiles. Also this situation happens rarely. The whole beauty of software is that you can customize it and make it your own. The only downside I see with customization is that it can be huge timesink. I guess to each his own, but I think you're really missing out. P. S. Backups.

Does anyone have a good solution for deploying dot files to vim easily? Like a vim package manager that's easily installed.
Post reply on HN