Live data from Hacker News

Using tmux properly

danielallendeutsch.com

131–140 of 218 posts

Re: Using tmux properly

#131
post #116

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…

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.

Re: Using tmux properly

#132
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!

Re: Using tmux properly

#134

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!

Copy mode is your friend and article does have a section o that so i think you should be using those settings.

Re: Using tmux properly

#135
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.

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.

Re: Using tmux properly

#136

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

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)

Re: Using tmux properly

#137

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

Re: Using tmux properly

#138
post #77

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

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…

You probably meant comely. At least, I think powerline is beautiful!

Re: Using tmux properly

#139

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

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

Re: Using tmux properly

#140
post #112

Earlier quoted context omitted.

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.

I'm willing to bet many employers really don't like their employees putting personal config files on a production server...

At my employer, we have unix accounts for every employee, and the system automatically synchronizes your dotfiles to each server.
Post reply on HN