I still don't quite understand the value of tmux, at least on a modern machine. If I need another terminal, I just pop open another terminal window and tile or tab it. If I want to keep a set of terminals organized, I use workspaces (at the OS level). 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 n…
Use fzf for tmux session switching
31–40 of 61 posts
Re: Use fzf for tmux session switching
#32Re: Use fzf for tmux session switching
#33I still don't quite understand the value of tmux, at least on a modern machine. If I need another terminal, I just pop open another terminal window and tile or tab it. If I want to keep a set of terminals organized, I use workspaces (at the OS level). 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 n…
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.
Re: Use fzf for tmux session switching
#34I still don't quite understand the value of tmux, at least on a modern machine. If I need another terminal, I just pop open another terminal window and tile or tab it. If I want to keep a set of terminals organized, I use workspaces (at the OS level). 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 n…
Imagine you're at work, and you have tmux running with 15 sessions to various machines. You go home, connect to that tmux session and you can keep working without having to re-connect/SSH and log into 15 machines and just continue where you left off. It's sort of like being able to RDP into the machine you were working on except it's text-based.
Re: Use fzf for tmux session switching
#35Earlier quoted context omitted.
You can ssh into a system and use tmux. Then you can detach from the session and when you come back a week later your tmux session is still there and you can continue with no friction. Also i find it interesting that you said you don't see its value and then continued to explain its value. For me it's definitely more common to work with systems/servers without a DE and WM. It's just better to handle this problem at t…
I’m a huge fan of `tmux -CC` for stuff like this!
Re: Use fzf for tmux session switching
#36I still don't quite understand the value of tmux, at least on a modern machine. If I need another terminal, I just pop open another terminal window and tile or tab it. If I want to keep a set of terminals organized, I use workspaces (at the OS level). 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 n…
- 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.
Re: Use fzf for tmux session switching
#37Have no relationship to it, just a happy "customer".
Re: Use fzf for tmux session switching
#38Earlier quoted context omitted.
Modern ssh supports forwarding of Unix domain sockets On remote host: $ tmux -S /tmp/remote.sock On local host: $ ssh -L /tmp/local.sock:/tmp/remote.sock user@remote $ tmux -S /tmp/local.sock attach I Typed this on a phone and not validated but it looks good to me right now
Have you tried this before? As far as I can tell, tmux expects to pass the client's terminal fd over the unix socket. When I try it, I get something like this in strace (passing fd 7): > 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 And then the client relays an error: > open terminal failed: not a terminal
Re: Use fzf for tmux session switching
#39If you like tmux, take a look at zellij ( https://github.com/zellij-org/zellij ), it is a modern alternative that has a lot of nice features (either developed, or on the roadmap) that tmux is missing. Have no relationship to it, just a happy "customer".
Re: Use fzf for tmux session switching
#40I'm still trying to assemble a way to put together the pieces to not only return to tmux sessions after detaching, but after detaching and the underlying server reboots . Playing around with CRIU, but trying to make it all automagic with nested PIDs, restore the screens and shell history buffers just how I left them, and implement the common use case of automatically re-establishing ssh connections remains a challeng…
https://help.ubuntu.com/community/Byobu
I'm sure there are newer/better? tools someone might recommend here too.