I can obviously see its value if there is no window manager or desktop environment on the system I'm using, but that's rare these days–if I'm working on a system with neither of these it's always over ssh. With a WM or DE it seems like tmux just adds a redundant layer of organization. What am I missing?

- You're connected to a remote host and you don't want an unexpected network issue to kill your session

- You want to be able to periodically check on the status of something on a remote host but don't feel like keeping the connection open all the time

- You want to connect to the same session from different clients

- You may need to restart you graphical session and don't want that to kill your terminal session

A really simple way you could get this working is what abduco and detach do: the demon just blindly shuttles input and output between the client tty and the virtual tty that the interactive process is running in. However, when you reconnect to an existing session, you get no context, because the server doesn't know what it would need to tell the client for it to reassemble the tty state.

In order for that to be possible, the daemon would need to keep track of the terminal state internally. It's really annoying that that's necessary because now your actual terminal emulator isn't directly communicating with the process it's displaying, and you won't be able to access any features of your terminal that the daemon doesn't support.

But once you already have this background process that's keeping track of terminal state, you might as well build in other features that would require that, like window management, otherwise people who want those features will end up having yet another layer of terminal. If you don't want those features, you can pretend they're not there.

It's sort of like being able to RDP into the machine you were working on except it's text-based.

So you can have tabs, splits, sessions, etc, all scriptable. Eg if I hit F1 in the shell I automatically get the command’s man page alongside the interactive shell.

I’ve also used it on occasions where I’ve needed to pair program with someone on a poor internet connection. We’d SSH into a common area and share a tmux session while chatting on a regular phone call. Thus no bandwidth heavy video conferencing.

It’s also been handy back before I worked fully remotely, I’d have a dedicated desktop running tmux and when I got home I would VPN into the office and resume the tmux session so I could resume where I left off.

Sure, you can do everything in a WM or DE, but I use Linux and macOS and it's nice to have the same configuration, keybindings and environment everywhere. I also find tmux more customizable than Gnome Terminal and easier to setup than st or urxvt.

Also - for long running processes, you can run stuff in a tmux session, go to bed, and wake up hours later and see exactly what happened. You can make the scrollback buffer as big as you want. My scrollback history is 50k lines, and that's totally fine. Of course the history is searchable with vim commands which is also nice.

Have no relationship to it, just a happy "customer".

I remember getting into Unix just a little before the time tmux came onto scene as the modern alternative to screen, and being in awe of all the people who had used screen long enough to have a list of things that could be modernised about it.

Now tmux is in that position!

Here's a nickel, kid...

https://en.m.wikipedia.org/wiki/DESQView

[1]: https://github.com/martanne/dvtm

i just wish i could connect to remote tmux back ends and recover windows as organized locally after a network cut.

so the local tmux presents the ui and performs session management, and the remote tmux backends hold the shells to provide network cut resilience, but still rely on the local ui instance for all user interaction (so cut/paste buffers and mousing and such are preserved)

On remote host:

    $ tmux -S /tmp/remote.sock
    <now detach from session: prefix d>

    $ ssh -L /tmp/local.sock:/tmp/remote.sock user@remote
    $ tmux -S /tmp/local.sock attach

  > sendmsg(5, {..., msg_control=[{cmsg_len=20, cmsg_level=SOL_SOCKET, cmsg_type=SCM_RIGHTS, cmsg_data=[7]}], msg_controllen=24, msg_flags=0}, 0) = 16

  > open terminal failed: not a terminal

problem is that it then doesn't work for local sessions. so you run it locally, which gives you local sessions and window management, but then all remote connections have to be via mosh -or- you mosh into the datacenter which is good for accessing infra, but leaves you having to run a separate instance for local work.

For example: SSH into server, start tmux on that system. If I am disconnected for some reason, SSH back into server, tmux attach -t 0 (or whatever ID I have) and I've recovered my session. Cut/copy/paste, mouse use, etc., are all treated as they are through any SSH session.

> the local tmux then remembers history and allows looking up commands on the remote shell, that would be huge.

I have an "outside" tmux session that can be run at either my desktop or laptop. When I start fresh, I open an outside tmux session and run a startup script. This preloads my outside session's copy buffers with named passwords from the `pass` password manager and creates windows to each of my remote sites. The shell for each of these windows is set to a script that does a simple loop of network check than attempt to ssh to the remote site. This ssh connection has an environment variable set that my remote bashrc will see. When this variable is set, my remote "inside" tmux connection is automatically recalled (or created if it doesn't exist.)

I have a script runs when I put the laptop to sleep that kills all the SSH connections cleanly, and when it wakes up again, every window reconnects to the remote machines and opens the remote tmux connections again. Everything is exactly where it was before and needs no intervention.

If the local tmux then remembers history and allows looking up commands on the remote shell, that would be huge.

Currently all my local work is saved but ssh into another machine? All that work is lost forever unless I explicitly save it.

$ ssh <hostname>

$ tmux --list-sessions

and

$ tmux --attach-session -t <session #>

?

I ended up writing a shell script [1] to use fzf to display a list not only of sessions, but the windows within each session.

Which I invoke from tmux like this:

bind C-a run-shell -b "$HOME/.local/bin/ftwind"

This has become so ingrained in my tmux workflow that I would be utterly helpless without it.

[1]: https://github.com/anelson/dotfiles/blob/master/home/.local/...

EDIT: for formatting

    rpick() {
        session=$(for i in $(tmux list-sessions -F '#S'); do
            echo -e -n "$i\t"; { { tmux capture-pane -p -t "$i" | tr '\n' ' '; } || true; }
            echo
        done | fzf --exact --reverse | cut -f 1)
        if [[ "$session" != "" ]]; then
            tmux attach -t "$session"
        fi
    }

https://help.ubuntu.com/community/Byobu

I'm sure there are newer/better? tools someone might recommend here too.

I've been using tmux for five or six years. In that time I've used Linux and MacOS and several different terminals. But how I navigate around a terminal has stayed the same thanks to tmux.

Another reason: put complex tmuxinator configs in source control and start up a bunch of stuff for your project with a single command.

I use zoxide now, it's slightly faster.

This allows me to have a very well-organized way of working over ssh.

Essentially you get all tmux functionality on the remote but with the local ergonomics you're already used to.

The home page also has some issues with elements clipping/overlaying and not registering clicks.

I say weirdly unfriendly because the graphic design is very $CURRENT_YEAR, which is usually designed mobile-first (since that’s where most of the traffic is these days). But the author clearly spends more time on the desktop (the article _is_ about tmux) and didnt check how it performs on mobile.

If it is just a safari issue I’m sympathetic. Testing for safari is a nightmare if you don’t have Apple hardware available.

Seems like a transcoding error for certain devices only then, if nobody else noticed it.

Unrelated, but it was completely impossible for me to put the video on full screen. It seems like the site did something with the scroll that prevented me from scrolling horizontally to click the full screen button.

One for my blog, podcast, 2 side projects, contract work, etc.. I usually have 6-10 sessions. Although I don't use fzf to search through them. The built in leader+s key makes finding and jumping between sessions painless, you also get the benefit of being able to see a preview of what's in the session.