It is no secret that most Linux power users use the shell for many tasks, as for people who know what they are doing, it can be quite efficient. In addition, there are some tasks that can only be carried out from the command line, although their number shrinks every year. However, these days we are spoiled because you can have one X session running lots of terminals at once. If you log into a server, it might not have X. Or you might log into a computer over a slow connection where X is painful to use. What then? The modern answer is the tmux terminal multiplexer, and [zserge] has a thoughtful introduction to how you can use tmux for improved productivity at the command line.
In particular, he shares some configuration and offers sound advice. For example, do you really need a status bar that shows you CPU load at all times? Cool, yes, but not always a practical win.
The traditional answer was to use screen. This is a venerable program that lets you do nearly the same thing as tmux, but the newer program has a few advantages:
- The tmux program is easier to configure
- You can command tmux through scripts easier
- Unicode support is better in tmux
On the other hand, screen is very mature whereas tmux is comparatively new. Still, tmux isn’t that new and works well for many people.
If you want even more features, try byobu which can use screen or tmux to do the actual work, whichever you prefer. We even talked about all three programs briefly in the past. Speaking of working in the terminal, we find it interesting that we can now run a pretty good version of bash on Windows and run Powershell on Linux.
tmux is pretty great, can confirm. I love working on the command line, though it took a lot longer to develop with it. From learning vim, to tmux to all the various tools, it takes a while to acclimate. But when you do, you’ll be able to manipulate the computer faster.
tmux uses literally 100x as much CPU time as screen for the same task.
see also: vim uses n^2 cpu time for repetition, while nvi is linear. even 10000 as a repeat factor will overwhelm vim on trivial operations.
If I follow your logic we should all go back to hex keypads and type CPU opcodes directly. Much less CPU time for processing input!
except in the poster’s example, the operations and user interface are mostly the same. why should we increase cpu load unless we can lower cognitive load.
😅😂🤣😁
Yeah, but neovim can’t run interactive consoles and the developers ware a—holes about it. And, I know I’m not the only persons those arrogant devs have pissed off. Stick to real vim.
“tmux uses literally 100x as much CPU time as screen for the same task.”
Wow! We can has quotation plz, kthx?!
Until some seconds ago I thought I only stick to screen because it can attach ‘real’ serial devices too. Now I have one reason more. \o/
And who the hill is vim?
>;-)
Next up: mosh?
I hadn’t heard of that one. Looks handy!
https://hackaday.com/2016/11/01/ssh-enters-the-mosh-pit/
Yeah, I use mosh with tmux all the time. Especially handy when connecting from a Chromebook that goes to sleep at every opportunity.
If you stick to text-based xterms, you don’t really need too much bandwidth to run X. We used to run it over 9600bps dialup connections (ok, using “Xremote” packet compression. But still…)
The argument about X doesn’t make a lot of sense.
X is a server that you run locally. You don’t remote to a computer to run X. All you have to do to run a remote program on your local X session is to use the -display option or set the environment variable to your computer address:
export DISPLAY=:0
And run any program.
The window will show up on your local X server.
You are assuming sufficient library support on the remote computer and a reasonably fast connection and open ports or ssh tunneling. Not everyone has all of those luxuries on all machines.
Same here. As long as you didn’t try to run FrameMaker, it worked fine. It was interesting to see how FrameMaker went about updating the screen. It was slow enough over 9600 baud that you could easily see its refresh strategy.
I still prefer screen. Last time I tried to switch to tmux I noticed input lag and some missed keystrokes here and there. tmux’s statusbar is nice, but screen seems more stable. I guess it being ~25 years old and all…
Things change, though, so I might try it out.
I’ve been using screen for a long time. Configuring it is a pain, but it is possible with work to get it to do what you need. One of my favorite recipes was to have a screenrc kick off multiple titled windows each dedicated to a remote ssh host, each in a while true {readln; ssh $host} loop. The environment was a managed security provider, a platform containing many linux hosts with short ssh timeouts. Deploying an update took hours during which time each host’s update needed to be verified through testing and log analysis.
The other major use is over a VPN. I don’t keep anything locally. All my employer’s code stays on-site. My code sessions persist as long as my VM stays up. I just access them from whichever machine I happen to be using. Desktop in the office? Laptop in a conference room, or from home over the VPN. It’s all the same. Checkouts and checkins are lightening fast too. I’ve been working that way for well over a decade.
I really like that you can attach to a screen session multiple times. (screen -x). Need one window tailing a logfile on a host as another host tries to connect to it? Easy.
The one thing that I really don’t like is the default keybinding. Ctrl-a is a useful bash keystroke for anyone long-enough in the beard to use command- and variable- substitution. I need to remap my brain to use Ctrl-x (which can also get to the beginning of the line) but somethings are so ingrained.
I tried tmux briefly, but I found it laggy. It was a while ago though, so maybe it’s improved.
Things I don’t like about screen:
– I know how to start an X/Y/Z-Modem transfer from within screen (f.ex. ctrl-a : !!!sx filename), but you can’t wrap this in a script to browse the filesystem to select a file
– If I am inside a screen session and I ssh onto another computer, it would be nice if I could start/attach a screen session there and have the two sessions merged.
Does tmux handle any of these better than screen?
I use sftp along the same session as ssh. That ability is built-in to Putty and MobaXterm and others. I run screen-in-screen as my normal workflow. there are advantages and disadvantages to this, as it creates a sort of hierarchical session layout that is logical but more complex.
tmux handles multiple sessions and splitting panes better than screen. for me I am satisfied with screen-in-a-screen and I don’t split panes. I tend to just bounce between two windows with ctrl-a ctrl-a
<3 it!
I send my notebook to sleep and when I wake it up again, I get all the same remote shells back as if nothing had happened.
Life is sooo much simpler with Mosh
The only tears: It doesn't work over Tor. :…(
Something is strange… my replies don’t get attached to where I did hit “reply”… maybe my privacy watchdogs are a bit misconfigured?
How is this in any way Linux specific?
I use combination of `screen` (ctrl-a based) and `tmux` (ctrl-b based); I start my main host with `screen`, in which I’d open `tmux` in that; then for each `screen` windows, I’d `ssh` to the other servers, and start `tmux` on each host. When I then connect from other machines, I’d `screen -r` to reattach to that screen session. (Feels weird, but that’s my solution so that I don’t need to tmux from a tmux session, been doing it this way for about 10 years now)