RHEL8 (Redhat enterprise Linux 8) has dropped support for my old friend screen. I had found a package somewhere that still worked for one new RHEL8 installation, but didn’t record where, and the version I installed on my most recently upgraded machine is crashing horribly.
Screen
Screen was originally recommended to me by Sam Bortman when I worked at IBM, and I am forever grateful to him, as it has been a godsend over the years. The basic idea is that you have have a single terminal session that not only saves all state, but also allows you to have multiple terminal “tabs” all controlled by that single master session. Since then, I no longer use nohup, and no longer try to run many background jobs anymore. Both attempting to background or nohup a job can be problematic, as there are a suprising number of tools and scripts that expect an active terminal. As well as the multiplexing functionality, running screen ensures that if you loose your network connection, or switch from wired to wireless and back, or go home or go to work, in all cases, you can resume your work where you left it.
A typical session looks something like the following:
i.e. plain old terminal, but three little “tabs” at the bottom, each representing a different shell on the same machine. In this case, I have my ovpn client running in window 0, am in my Tests/scripts/ directory in window 1, and have ‘git log –graph –decorate’ running in window 2. The second screenshot above shows the screen menu, listing all the different active windows.
screen can do window splitting vertically and horizontally too, but I’ve never used that. My needs are pretty simple:
- multiple windows, each with a different shell,
- an easy way to tab between the windows,
- an easy way to start a new shell.
I always found the screen key bindings to be somewhat cumbersome (example: control-A ” to start the window menu), and it didn’t take me long before I’d constructed a standard .screenrc for myself with a couple handy key bindings:
- F4: window menu
- F5: -1th window
- F6: previous window (after switching explicitly using key bindings or the menu)
- F8: +1th window
- F9: new window
I’ve used those key bindings for so many years that I feel lost without them!
With screen crashing on my constantly, my options were to find a stable package somewhere, build it myself (which I used to do all the time at IBM when I had to work on many Unix platforms simultaneously), or bite the bullet and see what it would take to switch to tmux.
tmux attach
I chose the latter, and with the help of some tutorials, it was pretty easy to make the switch to tmux. Startup is pretty easy:
(instead of screen -q)
and
(at is short for attach, what to use instead of screen -dr)
tmux bindings
All my trusty key bindings were easy to reimplement, requiring the following in my .tmux.conf:
bind-key -T root F4 list-windows bind-key -T root F5 select-window -p bind-key -T root F6 select-window -l bind-key -T root F8 select-window -n bind-key -T root F9 new-window
tmux command line
One of the nice things about tmux is that you don’t need a whole bunch of complex key bindings that are hard to remember, as you can do it all on the command line from within any tmux slave window. This means that you can also alias your tmux commands easily! Here are a couple examples:
alias weekly='tmux new-window -c ~/weeklyreports/01 -n weekly -t 1' alias master='tmux new-window -n master -c ~/master' alias tests='tmux new-window -n tests -c ~/Tests'
These new-window aliases change the name displayed in the bottom bar, and open a new terminal in a set of specific directories.
The UI is pretty much identical, and a session might look something like:
tmux prefix binding
The only other customization that I made to tmux was to override the default key binding, as tmux uses control-b instead of screen’s control-a. control-b is much easier to type than control-a, but messes up paging in vim, so I’ve reset it to control-n using:
With this, the rename window command becomes ‘control-n ,’.
I can’t think of anything that uses control-n, but if that choice ends up being intrusive, I’ll probably just unbind control-b and not bother with a prefix binding, since tmux has the full functioning command line options, and I can use easier to remember (or lookup) aliases.
Incompatibilities.
It looks like the bindings that I used above are valid with RHEL8 tmux-2.7, but not with RHEL7’s tmux-1.8. That’s a bit of a pain, and means that I’ll have to
- find alternate newer tmux packages for RHEL7, or
- figure out how to do the same bindings with tmux-1.8 and have different dot files, or
- keep on using screen until I’ve managed to upgrade all my machines to RHEL8.
Nothing is ever easy;)
we are moving over to RHEL7 for our main number crunchers. I guess I just used the terminal and am in the habit of having multiple open on multiple work-spaces. That is how I run things in the background and multiple jobs simultaneously. I try to not use multiple in the same work-space in different directories since I get confused, so I’ll have a work-space dedicated to my python scripts, one to monitor usage on the machine and a couple to be setting up runs in other directories, one of which is usually running a large job.
I’ve not seen tmux before, but maybe when it comes up again, I’ll try it.
Moving to RHEL7 or from it? RHEL7 has an ancient toolchain (gcc 4.8 based).
When you say that you use different workspaces, I assume you are talking about the old X11 virtual desktops? I liked those when I used X on Linux, but these days I only run my Linux machines headless, and am always ssh’ing into them. For that tmux or screen is really nice, since I can reestablish all my state after loosing network connectivity.
So much for a high tech company, since we work govt contracts, we are usually years behind the curve in upgrading our systems, this is a case in point. We are upgrading from SLES 11, so that tells you how far we are behind. The overriding factor in this upgrade is that the versions of some of our work horse tools would only run on RHEL 7 or better and our antiquated users/security apparatus wouldn’t let us update more regularly.
As for work spaces, they allow us to have 4 desktops open on the system, so I use each one for a different task like I said before. I’m really the only one who tries to be efficient with my usage, the others are pretty much neophytes wrt ‘nix tools and scripting.