My `~/.screenrc` has a comment at the top, which says I created it on "05-May-1994" (before I switched to ISO 8601 dates).
I'm no longer using `screen` on an HP 2392A dumb terminal and PP 14.4kbps modem. But `screen` is still coming in very handy, when working on servers, and for some kinds of developing&running long-running programs on the workstation laptop.
It's also fun, on the occasion that you introduce `screen` or `tmux` to programmers who've been using lesser tools, and they become an instant convert.
Incidentally, given how old the code is, and how there's the potential for various kinds of remote exploits via text (e.g., in SSH session, or in display of user-crafted strings in a console program), I wonder how recently someone has done a rigorous security audit of `screen`.
Related/funny: three years ago, someone found exactly such a bug because it was exploited against a Minecraft server they were running in screen (probably without the perpetrator understanding the root cause): https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0...
I just checked my .screenrc and while I don't have a date in it, the file was last modified in 2010. But that's around the time that I switched to tmux. I've been _very_ happy with tmux over the years…
Looking over the screen 5 release notes it's hard to tell what I've missed being out of that world over the past 15 years. Does anyone have a good rundown on their current differences?
There are bugs. But Screen itself is running locally and per-user?
I could imagine attacking from one tab (window) interacting with another tab but then the user runs already a harmful application. I worry more about everything containing Electron or similar built “web applications”.
For example, you start a `screen` session, and within one of those `screen` windows, you SSH to an untrusted remote system, and that remote system can then send arbitrary bytes to be interpreted by `screen`. If there's a bug, it's potentially remote system having arbitrary code execution capability on your local system that's running `screen`, under your UID, and then escalate from there.
This is why Linux should be taking things like the xz exploit more seriously and, at least, adopting a solution like firejail or bwrap everywhere.
It's not a perfect solution, but it's a step in the right direction towards patching the Unix model, so that programs don't have privileges they don't need.
Mobile Linux (Mer / SailfishOS) works this way to mimic app-based architectures. But, unlike Android, it still feels like regular Linux.
`screen` is trickier to sandbox/compartmentalize than some programs, because it needs permission to create and interact with ttys, most often with shells attached to them, and normally those shells can't be restricted.
I used to do training with this. Every student got a private username/password to connect to my laptop where their login shell connected to a specific window (to which only that user had access) in a shared screen session. They each had their own little environment to hack in. Then when we were doing exercises and people got stuck, I would put their screen up on the projector so we could discuss their code together.
Every other day there's an article about FOSS crisis, bubbles and unsustainability.
Meanwhile there's rock solid free software, just chugging along for longer than the people writing those articles have been alive.
I first started using Screen around '95, it was the nicest way to stay logged in to my ircII session while yielding the vt220 terminal to someone else for a while and going for a drink/smoke/walk.
Used it ever since, from terminal multiplexing to daemonizing services at a shoestring startup. I've used just a tiny subset the features I know it has, and probably don't know of many more, but it has served me well over the years.
> Changes the kind of error messages used by screen. When you are familiar with the game nethack, you may enjoy the nethack-style messages which will often blur the facts a little, but are much funnier to read. Anyway, standard messages often tend to be unclear as well.
Looks like a few QoL improvements and bug fixes. Nothing disruptive that would normally come with a major release version.
Looks like you can set a password on it now, which is cool (though I personally like having linux perms govern access to my screen/tmux). Multiinput sounds interesting as well, though in the past that was a feature I thought I'd love to have, but once I had I never use.
I'm glad to see Screen is still getting some love :-)
I ran screen for years before finally switching to tmux around 2011, and it's impact is still heavy as my tmux config is still rocking my "make tmux controls like screen while transitioning" setup which I intended to be temporary. Ctrl+a from my cold dead fingers
The one thing I hate about tmux is that it leaks env vars across instances:
# terminal 1, start a fresh first tmux session, which magically spawns a daemon with the same env
$ env FOO=bar tmux
# terminal 2, start another tmux session, which reuses the daemon's env
$ tmux
$ echo $FOO
bar
Try the same with `screen` and you're safe.
This is especially annoying when you're using, say, direnv, and project-specific env vars appear magically on an unrelated subsequent session because your first `tmux` turned out to be from a direnv-enabled directory, which polluted the global environment, which in turn pollutes every subsequent session environment as long as a session (not necessarily the original one) is alive.
Replace FOO with SOME_SECRET/ACCESS_KEY/TOKEN and you can actually accidentally expose/leak stuff or point to the wrong thing.
The unattended workaround is to have the tmux daemon spawn at login via `start-server` + enable some tmux settings like `exit-empty` plus some I can't recall regarding environment handling, but nobody does that.
You can start the server as a user session service if you have a service manager for that, like systemd, instead of needing to do it manually. For systemd specifically, tmux also supports socket activation for the server since some time ago, so you can do that to start it on-demand.
> The unattended workaround is to have the tmux daemon spawn at login via `start-server` + enable some tmux settings like `exit-empty` plus some I can't recall regarding environment handling, but nobody does that.
I just have my terminal emulator spin up tmux when it starts, and I start my terminal emulator from my desktop, so it always runs in a clean environment.
That conflicts with the standard Emacs binding to move to the beginning of the current line. Many years ago, I switched to C-z instead, on the theory that it is really easy to type C-z C-z when I really want to suspend whatever is currently running.
Pity that (AFAICT) terminals have no concept of Super and Hyper (USB doesn’t know about Hyper, either, but at least X11 does).
Our finger memory for ^a is now ^a-a. In all apps, everywhere. Mostly that just results in something like select-all+select-all, but occasionally it's awful
As a vim user, this was my attitude about ctrl-b ctrl-b for pgup because tmux uses that. But I got used to it. Like many a screen convert to tmux, I used to map to ctrl-a, but I found myself actually getting pinky/wrist pain from using just my left hand. As a non-emacs user, I'm not okay with that :P So ctrl-b forces me to use two hands.
C-f moves forward a character which is also useful. The easiest to type character that had the least impact I could find was to remap to C-j. Works well in both Dvorak and Qwerty layouts and that's the one emacs shortcut I use so infrequently that I can live with having to type it twice.
That’s my default as well, worked great, except on a machine with shared sessions, a test driver machine where several of us will login as the same user: some of those people come from windows machines where ctrl-space gets mapped to ctrl-@, which is NUL.
So we had to find another prefix for those machines; fortunately, tmux can have two.
This (space->@->NUL) is mentioned in the tmux docs, tbh.
C-o here. And C-x or C-p on a few rare nested screens in one particular screen session that I always have open. Those are identified by differently colored tabs in the hardstatus bar which is always visible.
This is actually a very handy readline shortcut to search for a character. Useful when editing long command lines. Granted, I use Ctrl-Shift-] more often (searches backwards).
Why did you switch to tmux? It seems to me that screen is more ubiquitous, and has more features. Having a modem is a pretty handy thing built into it.
Not GP, but ~15 years ago tmux offered a lot better screen splitting options and a few other features that screen did not. That's why I switched. I did continue to use screen at work because it was ubiquitous, but then sysads started installing tmux as well and that was no longer an issue.
screen has improved a lot since then, but it lagged behind substantially for years.
Also a benefit was actually being able to understand and edit my conf file without having to RTFM everything. Certainly not a reason to switch by itself, but a nice plus.
I was a very long time screen user and tried tmux early on in its existence. It was slow and different so I bailed back to screen. Last year I tried tmux again and have switched to it full time.
One of the things I like most about it is how easy it is to extend. In the role I was in last year, I'd have several long-lasting SSH sessions to various hosts. With a very simple bash script I was able to create a prompt in tmux that I could trigger to ask me where I wanted to ssh to. If I already had a connection to that host, it would switch me to that window, if not, it would create a new one and ssh to the host.
I wanted to do that in screen for years, but it just didn't have the features to facilitate it. On top of that I was able to easily re-map all of the keybindings to be just like screen for my muscle memory.
Ubuntu, and probably other distros, have screen as a hard dependency for doing upgrades to new release versions on the command line (do-release-upgrade command). I encountered it again just the other day while updating to an LTS version. It's a fantastic feature to have by default, in case your ssh connection gets dropped during the upgrade or something.
People say tmux is more powerful. Whatever that means?
Screen seems to cover all my needs and it learning it is easy. I came for the tabs (windows), sessions, copy and paste - but the must have for everyone is the scrollback buffer. You need it! Especially since we can scroll one the plain terminal.
> People say tmux is more powerful. Whatever that means?
I very rarely use screen/tmux nowadays, but as I recall tmux is a better fit for someone who wants to script their interaction. It makes it easy to send keys to other panes/windows in the session, and also to capture the content from other existing panes/windows.
when I worked in the embedded software industry long ago, I spent lots and lots of time connecting over serial ports to dev boards, using software like Minicom. Being able to do that in screen itself would be neat. Tmux does it.
Screen does connect to serial ports. Just open the device and append the line parameters you want to run on the port. Unlike modem dialers like Minicom, you don't have to screw around with on-hook off-hook distinctions or an intrusive TUI.
Exactly the other way around for me! I've been using screen since forever, and had no idea it could do that. Minicom I still know from the dialup dark ages.
Connecting to serial devices. You can for example get a USB uart dongle, and then connect cables to some device where you have uart pins.
Most recently I was doing something like that for an esp32 board, and used screen.
> Looks like you can set a password on it now, which is cool
I wish they didn't support that. There's not actually a security boundary there since you can't just reattach to another user's session anyway, and a lot of security people make stupid rules like "if something supports a password, you always have to use one".
I'm wondering if the use of wcwdith() will improve my luck with using UTF-8 characters in my caption and hardstatus lines. I'd like to be using nerdfonts in there but it just makes a mess.
The entire wchar_t API is hopelessly broken. It isn't guaranteed to represent Unicode nor is it guaranteed to be UTF-32. Unicode has a large number of codepoints designated as ambiguous width. This is largely due to existing narrow text presentation symbols being gifted a wide emoji representation. Which width is the default is heavily dependent on the font(s) in use and your rendering engine. Gnome VTE has a configuration option to set the default width for ambiguous codepoints.
Any program has to expect wide, narrow, or an inconsistent mixture of both if font substitutions are invoked. With no actual API to reliably discover a codepoint display width, your best option is to print some candidates and check the cursor position as a heuristic.
FWIW, wchar_t is guaranteed to be Unicode if __STDC_ISO_10646__ is defined, which is the case on Linux/glibc. It's too bad that other platforms are lagging behind on this - there's really no good reason to not guarantee this in 2024. Windows at least has the excuse of having wchar_t be 16-bit which they can't change for legacy compat reasons, but that doesn't explain why e.g. FreeBSD isn't there yet.
> I wonder how many people are using the default b key binding in tmux
I do not use C-b as the tmux prefix key because it interferes with my muscle memory for Emacs where C-b invokes backward-char (i.e., move the cursor back by character(s)).
So I use C-j instead as the prefix key. While C-j also happens to be a useful Emacs key-binding, I use it quite rarely in Emacs. As a result, I do not have strong muscle memory for C-j and I can use it as the prefix key in tmux quite comfortably.
I use back-tick `. For nested, it becomes `` or ````. For twice nested and I'm writing a shell script with ` instead of $( .. ) It's ```````` (I'm an emacs user, I need all the control characters :)
I also use backticks, and in 99.9% of cases it works like a charm. But then one day you paste a large file, and the gates of hell open. Tmux randomly opens windows, kills sessions, and launches nuclear missiles while processing all the backticks in the text.
Yeah, that's true. Tho for large pastes, I generally only do that in a locally running GUI emacs. For remote, I'll assemble the file and then scp.
Even without tmux, this can be an issue - a long time ago I was using the X windows "drag the selection" middle mouse button action and accidentally let go of the button while the cursor was over an emacs text window - I sent my first email to some big listserv I subscribed to consisting of weird fragments from the log file I was trying to paste.a
I use emacs so that meant practically every prefix character would annoy me at some point. I ended up using C-\ since that almost never gets used by anything (I was surprised it could even be detected by terminals).
C-\ is one of my favorite Emacs keybindings :). You use it to change input methods, in my case to write e.g. Greek letters and other Unicode symbols in plaintext files using TeX notation.
I sometimes like to program using Unicode variable names when doing physics/math, and this is an easy way to do so built into Emacs.
I use the default ctrl-b for tmux and changed screen to use the same. I like it because on my keyboard, a Kinesis Advantage, the (left) ctrl and b keys are right next to each other which makes them an easy combo.
Iam pretty sure that was a recommendation in the emacswiki to use ^P instead of ^A as prefix key (that must be 15+ years ago). I think I didnt invest to much energy to think about an alternative. I almost never use ^P in my terminal emulator, but I use ^A all the time.
I usually never do heavy editing in a tmux window. Rarely I use emacs in a terminal window these days. I use tramp to remote connect and edit comfortably in my X session.
I would advice to use tmux. It's not worth it to keep fighting with that issue.
Take this from someone that used GNU Screen from ca 2002-2024. Yep, I just recently switched, because of truecolor and because of the issue you mention.
Of course GNU Screen is in my heart. Where it stays.
I used to be an avid user of screen, then later on tmux. My terminal directly launched a session upon opening.
But something that was always bugging me was the "ssh unawareness" - I've always wanted to be able to do splits on the remote end, but that was simply not possible without nesting sessions.
Now, I've switched my terminal to wezterm, which fills all my multiplexing needs, as it supports this exact "remote-or-local-splits" usecase (with some setup, of course).
[EDIT]: and on the topic of modern terminal emulator vs screen/tmux type solutions ... there is of course some feature overlap for which modern terminal emulators are clearly better (my opinion), such as window / pane management.
However, screen and tmux are simply amazing for long-term backgrounding of tasks and/or sessions.
There are some "daemon"-type tasks that I almost exclusively run under screen, only moving them to a systemd-type session control system long after they've been properly debugged and tested.
There are also some semi-permanently running shell sessions that keep alive with screen on remote servers to instantly recover full context of what I was doing there, sometimes weeks apart (old brains become forgetful and need crutches).
Are modern term emulator like wezterm capable of pulling that off these days ?
What do you use Zellij for that isn't covered by Wezterm? I used Zellij in Alacritty and now in Foot, but recently tried Wezterm and the features it offered really seemed to match what Zellij offers. I didn't need two ways to do splits, tabs, sessions so I'm back to Foot/Zellij, but was just curious to your use-case.
> Are there particular pros and cont to using screen or tmux
If you mean vs. not using screen or tmux, the pros to using (among many) are:
1) you get plural terminals in one "window" (xterm, remote ssh session, etc.) that you can switch between with hot-keys. This has a larger advantage for remote ssh sessions, where one ssh connection can be used for plural remote terminals, than it does locally where you could simply launch a second xterm.
2) you gain the ability to 'disconnect' from the screen session (I presume tmux offers a similar feature). This works just like 'disconnect' from a RDP session. All your remote terminals remain active, open, and waiting. When you next ssh in, you simply 'reconnect' and everything is there just as you left it when you disconnected. This helps for both flaky connections where the link drops at times as well as the "done for the day" "disconnect".
3) for screen, there is a screen built in 'copy and paste' controlled by the screen hotkeys, so if you are in a situation where you have no local copy/paste (unlikely in 2024, much more likely back in the days of VT100's) you can still select and copy portions of the screen to a 'clipboard' for pasting into somewhere else. I don't know if tmux offers something similar.
4) screen also offers 'scrollback buffering' (it will retain the last X lines that scroll off the top of your viewport) and has a feature to let you "look back" at what just scrolled out of view. This is less useful in 2024 with xterms/urxvt's offering the same feature locally, but for a remote ssh connect this does give you 'scrollback' that is specific to each screen terminal you have open instead of all mixed up in the local viewer.
There's more advantages, but those are the big ones, and the 'disconnect/reconnect' one is huge if you use the terminal a lot and also often connect via ssh from remote locations.
It functions like a lightweight version of minicom (which is a terminal program), which when connected to the console port of many network appliance hardware devices (like switches, routers, access points, etc) allows local access to the device (much like having a monitor/keyboard/mouse connected to a computer) without having to rely on a network connection.
I loved Zellij, it was the first time a terminal multiplexer felt like it added significant value without significant work from me.
The only problem is that projects dealing with network stuff require aging just the way wines do. Networks are unreliable and can get into a thousand different states that are a combination of local connection issues, remote issues, input problems, etc etc. I found (when I tried it a year or two ago) that Zellij could handle a decent amount of such weird states, but not all of them. There was noticeably more "stuck" states it could get into.
It was a pleasure to use in every other way, and maybe this has become much less of a problem in the intervening time. I'm pretty sure that Zellij is going to be my one true term mux for the future, just not sure that future has started yet.
I've used tmux for ages and would go back if zellij ceased to exist, but I found zellij so much more discoverable. Want to do something new? Chances are there's a menu for it.
Long ago i decided to train myself on a lightweight development environment available on all platforms so i can carry it around easily in my head. I came up with GNU Screen + dvtm tiling window manager(as needed within each screen window) + Vim (with Cscope + GNU Global/Ctags). I generally leave this running on a central server/my local desktop/laptop, connect from anywhere anytime (detach/reattach) and continue working. From this central screen session i can connect to various other machines (including embedded devices via serial/USB/Network) allocating one screen window running dvtm (allows me to run multiple shell sessions) to each machine. This keeps everything clean and nicely organized in my head thus allowing me to carry it to any needed platform.
Tmux allows you to start multiple windows and send commands to them.
An example from man tmux -
"
refresh-client -t/dev/ttyp2
rename-session -tfirst newname
set-option -wt:0 monitor-activity on
new-window ; split-window -d
bind-key R source-file ~/.tmux.conf \; \
display-message "source-file done"
"
Screen has no equivalent besides manually using the keybinds.
I believe tmux has some better mechanics around the attach/detach but it eludes me atm what was better.
Basically what made me switch in the first place from screen to tmux was wanting a split window watch compile and a logfile to run automatically with one command.
I started using tmux because 12 years ago all people said it is better than screen. I didn't use screen much myself. Sometime I read a comparison and it seems screen is good for my usage. But I didn't want to leave tmux because I wrote a wrapper around it to have more human readable syntax and it just works. And I don't want to work on modifying it for screen.
I don't use most of tmux or screen functionalities anyway. Mostly it is a way of avoiding multiple ssh connections and to run things when I close the laptop.
Almost the same for me. I just switched to byobu in early 2010s instead of creating a wrapper myself. Haven't felt the need to check anything new since.
I was just taking a look at screen's source to try to figure out how hard it would be add a feature I want. I want an option when using screen to talk to a serial port to reverse the order of the bits in each character.
Does anyone know of any readily available serial port reader/writer for Unix and Unix-like systems that already has that?
I realize it seems like a really weird thing to want. I'm going some things with a small microcontroller (ATTiny 85). It does not have a UART, so right now when when I want to use serial for debugging I just bit bang it. The MCU does have a thing they call Universal Serial Interface (USI), which provides hardware support for shifting a byte in or out over a GPIO pin timed by a clock. USI is basically building blocks in hardware for the lowest level parts of serial communication. It does the things that can be hard in software because of timing, leaving the software to deal with the higher level aspects of the protocol.
I want to switch from bit banging to USI. Unfortunately when USI shifts a byte out of its send register to a pin, it shifts from the most significant bit side of the registers. UART protocol, which is what computers expect, wants the least significant bit first, so you've got to reverse the bytes before loading them into the USI's output register.
(They probably made USI MSB first because the serial protocols most likely for it to be used for are I2C and SPI. I2C is MSB first. SPI can go either way but MSB first is more common).
It's only a few instructions to do that swap, but MCUs can be quite constrained on space so it would be nice to not have to bother and instead do the swap on the receiving side.
You could look at socat to create virtual serial ports and insert your byte reversal in there. Or there are things like ttymux (of various flavours() that can probably be adapted.
But here's another way of approaching the same problem:
Emacs can serve as a superlative terminal multiplexer if you're willing to give it a shot or if you're already an Emacs user, but do not want to use Emacs's TRAMP (remote editing) functionality:
1. Emacs can run as a server, so you can run it on your remote servers and connect to it with `emacsclient' via SSH. This has the added advantage that $EDITOR stuff will open in your active Emacs session if you want it to.
2. You can use Emacs's builtin shells or terminal emulators (and/or install vterm for a more faithful terminal emulation experience).
3. It is obviously a capable editor also, it goes without saying.
4. Windowing is better in Emacs than the other muxers, and more advanced. In terminal Emacs frames ("windows" everywhere else) serve as decent facsimiles for workspaces.
5. You can use tools like Magit for git management.
... plus all the other benefits of Emacs.
I still prefer TRAMP and GUI emacs, but terminal Emacs does have its own advantages.
I love Emacs but using it as a terminal sucks. Eshell is not a proper terminal emulator. Using it with programs that take control of the entire terminal window like less is janky. Stuff like ncurses based TUIs don't work at all.
Editing with TRAMP, on the other hand, is a pleasure.
There is a difference between plain shells (as in M-x shell and variants) and terminals (as in M-x vterm, or ansi-term) in Emacs. The former are essentially an infinite buffer without ncurses; the latter are full terminals with ncruses and a shell. Emacs calls the terminals of plain shells “dumb terminals”, to not raise any hopes. I personally love their infinte length and ability to edit them just like any other buffer. I typically have dozens to hundreds of shells but only few true terminals multiplexed in a long running Emacs session.
All you say is true... But I still run emacs in screen :P
I know I should run a single emacs instances and use projectile or whatever to switch context, but for me it's just easier to run many screen sessions (with descriptive names via `screen -S my-session-name`, attaching via `screen -r my-session-name`) and an emacs instance for each screen session.
One day I'll improve my emacs-fu and I'll use a single emacs instance for everything.
I also prefer many Emacs instances. It simplifies some things like e.g. making Emacs packages aware of Python virtual environments if you can just run a separate Emacs instance per environment, instead of stuff like direnv.el.
> In terminal Emacs frames ("windows" everywhere else) serve as decent facsimiles for workspaces.
I would recommend enabling tab-bar-mode instead for this – it’s in Emacs core, and the tabs are really “numbered window configurations” that act very similarly to what screen/tmux calls “windows”.
I feel Emacs frames are in some ways more analogous to screen/tmux sessions.
I use mintty on Windows (Cygwin) and like the standard "select with mouse does automatically copy to clipboard and rmb pastes into the terminal".
My issue with screen and tmux is that they break mouse selection. All I know is that it is possible to select text and it gets copied into a buffer, but my terminal can't interact with this buffer.
tmux at least does allow multiline selection with the mouse in a pane, not copying the entire line across multiple vertically split panes, but limiting itself to the active pane. Yet I then have no way to get that copied text into the OS's clipboard.
And with screen, if there are multiple vertically split panes, it will select the entire text in that line, not caring about the fact that these panes have an entirely different content.
It makes me feel bad about myself when I see people showing their tmux skills, because I can't use it due to my demand of easily copying into and from the native clipboard.
For me screen has turned into what I use to run long-running processes, and tmux what I use to create multipane layouts which mostly serve as dashboards, showing the output of `docker log --follow` or screens of long-running processes.
Both tools are really great, but I know that I'll not be able to use them properly. Multiple mintty terminals are what I have to settle with.
Could it be possible to write some kind of tool which watches such a buffer and then sends it via HTTP to my machine, which then moves it into the clipboard (and the other way around)?
I'm no longer using `screen` on an HP 2392A dumb terminal and PP 14.4kbps modem. But `screen` is still coming in very handy, when working on servers, and for some kinds of developing&running long-running programs on the workstation laptop.
It's also fun, on the occasion that you introduce `screen` or `tmux` to programmers who've been using lesser tools, and they become an instant convert.
Incidentally, given how old the code is, and how there's the potential for various kinds of remote exploits via text (e.g., in SSH session, or in display of user-crafted strings in a console program), I wonder how recently someone has done a rigorous security audit of `screen`.