Live data from Hacker News

Getting Started with Tmux

ittavern.com

131–140 of 160 posts

Re: Getting Started with Tmux

#131
Here's a kind of dumb question:

Are the primary usecases of this for SSH, or for non-tiling desktop environments? People say a lot of good stuff about it, but I struggle to figure out what it can do for me when I'm just doing stuff on a local computer, where I can just create new terminal windows.

Re: Getting Started with Tmux

#132

I've used Tmux/Screen the few times I've had to be in an actual terminal, but don't really see the use for them when using a GUI terminal emulator. I just open new tabs or (rarely) windows as needed. Could anyone using these explain what it provides that you find useful in practice? I rarely ever need persistence of shell when I close the console, is that a common need? Familiarity/muscle memory of shortcuts is a val…

Doesn't it drive you crazy to lose your work whenever X11/Wayland crashes, or you have to kill your display server to diagnose a problem, or you accidentally close a terminal window? tmux preserves everything for you unless you explicitly kill it, or you have to reboot. I started using Screen like 20 years ago (and later moved to tmux) and I can't go back to doing real work in a "bare" terminal window. It would feel…

Well I use Mac these days, but I've used FreeBSD and Linux in the past as a desktop and don't remember this at all.

In the unlikely event everything locks up and dies then mostly I'll just lose vim sessions, and I can vim -r to recover the data. This is rare, and vim complains at you when you start it up on a file after it has crashed.

You'd lose the window layouts, but I don't use crazy window layouts, generally no more than two panes for code+tests (running tests I let it flip to fullscreen and scroll and I've got that bound to a key combo in .vimrc). If I had crazy window layouts I'd probably setup a command alias to make it easy to pop them up.

When it comes to commands and such, I just use the command history which is my memory. When it comes to running daemon process I would detach them if I cared (and generally I've got command history so I don't care, I'll just restart it, no matter how arbitrarily complicated it was to get the command running).

Similarly, though, I don't horde tabs and I HATE it when the O/S starts popping open all the windows I had open after a reboot to upgrade the O/S or whatever. I try to run pretty much "statelessly" so that I can wipe everything and start over from nothing easily enough (obviously not really "statelessly" since e.g. slack remembers all kinds of state about what I've done in the past, but I don't have to remember any of that)

And my memory does suck, but I know how to pull things out of command history, internet search, google history, etc. If I need to track stuff, then I use a tool to track it so that it becomes persistent (Zotero has now replaced my folder full of PDFs, I take notes in Obsidian). I don't know what I would ever lose in a terminal window that I fundamentally couldn't get back (and if I ever really needed something such as some unique failure I'd probably take a quick screen shot or copypasta into a note file somewhere -- I'll commonly copy test failures into code comments temporarily while I'm working on them -- sometimes these get promoted to documentation in particularly hairy edge cases).

So I literally just pulled up iTerm in activity window and force killed it and I have no idea what disappeared, but I don't care... Based on the saved command history I can see I likely didn't lose anything at all...

Re: Getting Started with Tmux

#133
post #128

Earlier quoted context omitted.

I've bound the keys 'v' and 's' for vertical and horizontal splitting to match Vim's default bindings. What tmux calls horizontal and vertical splits is inverse of those in Vim - hence -h flag for what most would call as vertical split. I suspect one of the authors was Australian!

There is ambiguity in vertical / horizontal split. Does it refer to the "cut" or the result? In Sway and i3 if I make a vertical split and open a new window, it appears below (thus vertical), but the split was like a cut horizontally across. I've seen some people use the - and | keys for tmux splits which kind of avoids the language issues and turns it into which way the new line is drawn.

I recognize the ambiguity. I tend to think in terms of the result; so, in vim, I do vertical splitting because I want that result where the cleaving line runs vertically.

Re: Getting Started with Tmux

#134
post #90
post #86

These days I mostly stopped using tmux over ssh. If one can install software on a remote system, then I just run a VNC server and use a GUI editor or IDE to edit things. The big plus of this is that copy-paste just works and I can use various shortcuts that are problematic inside a terminal emulator. And if one can use xpra, then running a GUI terminal remotely over a fat but high-latency link can be faster than usin…

> For running commands I just run ssh host command then That's fine, right up until the point you're running a command (or a series of commands) that change things on the machine and your connection gets broken. When that happens there's a very good chance the command being executed will fail in some fashion. If you're very lucky it won't be a big deal, but depending on what you're doing it could be dangerous. I woul…

> That's fine, right up until the point you're running a command (or a series of commands) that change things on the machine and your connection gets broken. When that happens there's a very good chance the command being executed will fail in some fashion. If you're very lucky it won't be a big deal, but depending on what you're doing it could be dangerous.

I spent 5 years at Amazon (back a long time ago) being incredibly aggressive with command line root-trust from the old bastion host they had there, working up to regularly executing ssh commands to all 30,000 servers (like I said it was a long time ago, but that's still a considerable stack) every single day. It is the kind of idea that gives a lot of people the vapours to think about, and I wouldn't recommend it if you had good alternatives. But Amazon never turned into a smoking hole, and I never once saw this kind of problem. I certainly had to deal with network issues, and the scripts I used were pretty robust against problems. Most often servers would be crashed and fail to ping, packets would get lost but retransmissions would succeed, or the kernel would be hung only responding to interrupts and userspace was all deadlocked, but sometimes the servers had some resource starvation issues and it would just be very slow and the command would timeout. Nothing bad every happened. I occupy some weird space though where I'm stupid enough to try these kinds of things and just careful enough to not get bitten by them. I've also been a trained cave diver for over a decade now as well (if you get the training and follow the rules, it is safer than driving on the roads in Mexico).

And really you should always be using configuration management to change the state of servers and should have some kind of agent doing that automatically for you (although I've broken that rule probably a thousand times myself), and you should also ensure that what you're doing is 'idempotent', so that if it fails due to some transient error then you can just keep on hammering on the server and the next time or the time after that or whatever it will fix itself. This is the "self-healing" or "computer immunology" concept of configuration management that Mark Burgess came up with back in 1998 or so. If the process gets interrupted just run the process again. That may require some care taken around intermediate states and recovery from intermediate states, but that is just config management 101.

Re: Getting Started with Tmux

#135

Earlier quoted context omitted.

Interestingly enough, one of the stated goals of kitty is to make the usage of tmux unnecessary. Considering your comment (and many others like it), I don't think that has quite worked out. Still, kitty is one of my favorite terminal emulators and I'd urge anyone who hasn't tried it to give it a shot.

I use kitty locally and only usr tmux on remote servers where I would not like to lose my session. Running remote tmux inside a local tmux is just to error prone and forces you to remember different bindings.

There is an approach to use tmux inside tmux without using different set of keybindings. That's what I have been using for couple years and I really like the setup. I have the following binding in my local machine:

    bind -T root F3 \
      set prefix None \;\
      set key-table off \;\
      set status-left '#[bg=#C678DD,fg=#2C323C](pass-#S)' \;\
      set status-style bg=#E06C75 \;\
      set window-status-current-style bg=magenta,fg=black \;\
      refresh-client -S;

    bind -T off F3 \
      set -u prefix \;\
      set -u key-table \;\
      set -u status-left \;\
      set -u status-style \;\
      set -u window-status-current-style \;\
      refresh-client -S;
This way, pressing F3 in local machine disables the prefix and I can use remote tmux as if it is local. When I want to get to local tmux, I press F3 once and I am back to local tmux. I use highlighting to easily show that local prefix is disabled.

Re: Getting Started with Tmux

#136
post #90
post #86

These days I mostly stopped using tmux over ssh. If one can install software on a remote system, then I just run a VNC server and use a GUI editor or IDE to edit things. The big plus of this is that copy-paste just works and I can use various shortcuts that are problematic inside a terminal emulator. And if one can use xpra, then running a GUI terminal remotely over a fat but high-latency link can be faster than usin…

> For running commands I just run ssh host command then That's fine, right up until the point you're running a command (or a series of commands) that change things on the machine and your connection gets broken. When that happens there's a very good chance the command being executed will fail in some fashion. If you're very lucky it won't be a big deal, but depending on what you're doing it could be dangerous. I woul…

Typically the commands that I run this way were idempotent so it does not matter if they fail. On the other hand having them in the local shell history is nice since I can preserve that while the remote system can be a transient container where history is not preserved between restarts or it may not even have bash in the first place, just a minimal shell with no history saving support. Plus tmux or screen even when available still sucks at quickly scrolling with mouse and copying the selected text.

Re: Getting Started with Tmux

#137
This is my single most repeated action on a normal terminal window:

* Clear and discard all scrollback history: Ctrl+Shift+K

* Start a program run

* Select all output: Ctrl+Shift+A

* Copy it: Ctrl+Shift+C

* Paste it somewhere else

A total of 3 key combinations, that are now second nature.

When I installed Tmux and tried to replicate this, I only found a sea of gotchas. No key binding by default for clearing the scroll; similarly, no way to select all text with one single keypress; no way to copy the selected text so I can paste it in other applications.

Given enough time, of course, all of these can be solved one by one, assuming enough motivation and free time (use custom configs, configure xclip, etc) but the default onboarding experience was a bit poor, to be honest.

This is not a fault specifically of Tmux, but more of the typical lack of cohesion between different components that are considered independent tools albeit from the user pow they are arguably part of the same thing.

I might have to revisit Tmux by means of Byobu [0] and see if this time it clicks.

[0]: https://www.byobu.org/

Re: Getting Started with Tmux

#138
Favorite tmux conf change: new pane/window in cwd

    # split in pane cwd
    bind '"' split-window -c "#{pane_current_path}"
    bind % split-window -h -c "#{pane_current_path}"
    bind c new-window -c "#{pane_current_path}"

Re: Getting Started with Tmux

#139

Here's a kind of dumb question: Are the primary usecases of this for SSH, or for non-tiling desktop environments? People say a lot of good stuff about it, but I struggle to figure out what it can do for me when I'm just doing stuff on a local computer, where I can just create new terminal windows.

To some extent it's mostly equivalent to using terminal windows. You can do other stuff w/ it but most of the time it's for managing lots of panes/windows. Personally I really just like its UI and it works really well w/ my workflows. I actually used to run tmux + vim splits + i3wm and managed to find myself really using the heck out of some really gnarly tiling schemes at times. Talking 10+ panes of really tiny windows at once, just on the fly. And then when I need to zoom in on one file in some pane, boom, ctrl+b+z and it's maximized.
Post reply on HN