Posts by tblancher

GNU screen 5 proves it's still got game even after 37 years

Re: tiling

If you rely on GNU Screen (or any terminal multiplexer) for everything you do, it behooves you to add it to your shell's startup script (.bash_profile, .zshrc, etc.). You'll need to add logic to ensure you don't spawn a new session every time you launch the shell, open a new window/pane, or source your shell's startup file, but it can be done.

Also, since I use a terminal multiplexer everywhere, I prefer a terminal emulator which doesn't do a lot of internal tabs, split panes, scrollbars, etc.; I use the terminal multiplexer for that. Alacritty is one such terminal emulator; I'm not aware of any others that are like this.

And if you like to have two terminal emulators tiled side by side, you should also get a tiling window manager. But since I use a terminal multiplexer, I don't typically rely on the window manager to handle it, I just have a vertically split window in the terminal multiplexer. Thus, I never need more than one terminal emulator window open at any time.

Re: GNU screen use case

I think the use case you described for the uninitiated is a bit muddy and unclear. My first reaction is that you had it backwards, you connect to the remote system first and then run Screen (to use your disambiguation) there, not locally. That way if your connection dies or you shut down your local terminal emulator, you can reconnect to the remote machine and pick up where you left off.

I think you used the word "connect" ambiguously, or at least too soon. I think it would have served readers better had you mentioned sessions first, and used the word "attach" instead.

Screen (or tmux, etc.) can launch and attach to a session that can optionally be named. The session typically runs your preferred interactive shell, but it can be directed to run any CLI program. You can then detach from this session, close your terminal emulator, open a new, possibly different terminal emulator, or even connect remotely from another machine, and reattach to this session without losing your place (the program running in the session has no idea that anything happened). The only thing that would kill the session would be a reboot, or a signal that tells the program running in the session to exit. Having the ability to add windows and panes to a session allows you to run more than one CLI program within the session; detach and reattach from the session, and everything in it keeps on running.

One bonus where I really exercised the power of GNU Screen was when I was doing tech support for a company that produced hardware for Linux. We had out of tree driver modules that the end user needed to compile to use the hardware, and many times a week I'd have to request that they share SSH credentials so I could log in and figure out what they were doing wrong. To instill trust I'd always fire up Screen and have both of us attach to the same session, so they could either show me what they were doing, or let me drive and they could see everything I was doing. If they were really paranoid I would always recommend they let me connect with an unprivileged account, and then they could escalate my privileges without disclosing their root password.

Nowadays I don't use GNU Screen anymore, for a number of different reasons. First, I didn't like that by default there is no visible indication that you're in a Screen session. Also, its default prefix key conflicts with the emacs beginning of line key (I think it's really bizarre that a pair of GNU programs has such an incompatibility by default); this is especially apparent if you use emacs mode in your shell. I also found that the Screen configuration is rather ad hoc and not very orthogonal. It also didn't seem very scriptable the last time I used it. Another reason which is quite anecdotal: I had a VP of engineering forbid me from using Screen on some Linux servers since he thought it was consuming too many resources. I never could disprove that, but it made managing those servers that much more difficult. I don't know if GNU Screen 5 addresses any of these issues, but it's already too late.

Now I use tmux for everything. Because it is so scriptable, and its configuration is much more orthogonal, I have it integrated into my .zshrc everywhere, on Linux and macOS. I have a local tmux server with multiple named sessions (one session for each host I regularly connect to over SSH), plus a remote tmux server on each host, with various named sessions specific for that host. So yes, I run nested tmux sessions all the time, against conventional wisdom. I don't think I'll ever go back to Screen, tmux is so embedded in my workflow it would be too much effort to change it back.