GNU Screen 5.0 Released

My `~&#x2F;.screenrc` has a comment at the top, which says I created it on &quot;05-May-1994&quot; (before I switched to ISO 8601 dates).<p>I&#x27;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&amp;running long-running programs on the workstation laptop.<p>It&#x27;s also fun, on the occasion that you introduce `screen` or `tmux` to programmers who&#x27;ve been using lesser tools, and they become an instant convert.<p>Incidentally, given how old the code is, and how there&#x27;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`.

Every other day there&#x27;s an article about FOSS crisis, bubbles and unsustainability.<p>Meanwhile there&#x27;s rock solid free software, just chugging along for longer than the people writing those articles have been alive.<p>I first started using Screen around &#x27;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&#x2F;smoke&#x2F;walk.<p>Used it ever since, from terminal multiplexing to daemonizing services at a shoestring startup. I&#x27;ve used just a tiny subset the features I know it has, and probably don&#x27;t know of many more, but it has served me well over the years.<p>Congrats on the release!

&gt; Removed commands: - nethack<p><a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;screen&#x2F;manual&#x2F;html_node&#x2F;Nethack.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;screen&#x2F;manual&#x2F;html_node&#x2F;Nethack...</a><p>&gt; 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.<p>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&#x2F;tmux). Multiinput sounds interesting as well, though in the past that was a feature I thought I&#x27;d love to have, but once I had I never use.<p>I&#x27;m glad to see Screen is still getting some love :-)<p>I ran screen for years before finally switching to tmux around 2011, and it&#x27;s impact is still heavy as my tmux config is still rocking my &quot;make tmux controls like screen while transitioning&quot; setup which I intended to be temporary. Ctrl+a from my cold dead fingers

Finally :)<p>I’m waiting for a year that we don’t have to push <i>Escape</i> twice in Vim&#x2F;Neovim. Some mouse emulation was catching it.<p><a href="https:&#x2F;&#x2F;savannah.gnu.org&#x2F;bugs&#x2F;?57748" rel="nofollow">https:&#x2F;&#x2F;savannah.gnu.org&#x2F;bugs&#x2F;?57748</a> <a href="https:&#x2F;&#x2F;superuser.com&#x2F;questions&#x2F;1675761&#x2F;why-does-gnu-screen-cause-me-to-have-to-press-esc-twice-in-vim" rel="nofollow">https:&#x2F;&#x2F;superuser.com&#x2F;questions&#x2F;1675761&#x2F;why-does-gnu-screen-...</a><p>I should write the developers a note with thanks :)

I used to be an avid user of screen, then later on tmux. My terminal directly launched a session upon opening.<p>But something that was always bugging me was the &quot;ssh unawareness&quot; - I&#x27;ve always wanted to be able to do splits on the remote end, but that was simply not possible without nesting sessions.<p>Now, I&#x27;ve switched my terminal to wezterm, which fills all my multiplexing needs, as it supports this exact &quot;remote-or-local-splits&quot; usecase (with some setup, of course).

To anyone to perhaps who has used both a lot:<p>* Are there particular pros and cons to using <i>screen</i> or <i>tmux</i>?<p>(I&#x27;m generally on macOS for work, but never really go into using iTerm2, so that integration isn&#x27;t a big thing for me personally.)<p>Edit: I mean why use one over the other. I generally use something on the destination host I&#x27;m SSHing to in case the network goes sideways.

I started using tmux because 12 years ago all people said it is better than screen. I didn&#x27;t use screen much myself. Sometime I read a comparison and it seems screen is good for my usage. But I didn&#x27;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&#x27;t want to work on modifying it for screen.<p>I don&#x27;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.

I was just taking a look at screen&#x27;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.<p>Does anyone know of any readily available serial port reader&#x2F;writer for Unix and Unix-like systems that already has that?<p>I realize it seems like a really weird thing to want. I&#x27;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.<p>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&#x27;ve got to reverse the bytes before loading them into the USI&#x27;s output register.<p>(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).<p>It&#x27;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.

I wish they&#x27;d do something about <a href="https:&#x2F;&#x2F;savannah.gnu.org&#x2F;bugs&#x2F;?63341" rel="nofollow">https:&#x2F;&#x2F;savannah.gnu.org&#x2F;bugs&#x2F;?63341</a>, where switching to &quot;copy mode&quot; blocks the process without warning.

I notice that Screen has moved into EPEL, while tmux is in baseos for the RHEL family.<p>Is there anything compelling in the latest release?

Very nice, will need to give it a try. For my use there is no difference wuth screen vs tmux except for attaching.<p>In rare cases I need to do odd things with screen, but that was on AIX and I think Linux. NetBSD no issues. Maybe that works better now.<p>One thing I do like, screen is a lighter in resource usage these days.

Screen, tmux, et al. are great.<p>But here&#x27;s another way of approaching the same problem:<p>Emacs can serve as a superlative terminal multiplexer if you&#x27;re willing to give it a shot or if you&#x27;re already an Emacs user, but do not want to use Emacs&#x27;s TRAMP (remote editing) functionality:<p>1. Emacs can run as a server, so you can run it on your remote servers and connect to it with `emacsclient&#x27; via SSH. This has the added advantage that $EDITOR stuff will open in your active Emacs session if you want it to.<p>2. You can use Emacs&#x27;s builtin shells or terminal emulators (and&#x2F;or install vterm for a more faithful terminal emulation experience).<p>3. It is obviously a capable editor also, it goes without saying.<p>4. Windowing is better in Emacs than the other muxers, and more advanced. In terminal Emacs frames (&quot;windows&quot; everywhere else) serve as decent facsimiles for workspaces.<p>5. You can use tools like Magit for git management.<p>... plus all the other benefits of Emacs.<p>I still prefer TRAMP and GUI emacs, but terminal Emacs does have its own advantages.

But the AI generated article from the front page yesterday said I shouldn’t use Screens anymore… &#x2F;s

I use mintty on Windows (Cygwin) and like the standard &quot;select with mouse does automatically copy to clipboard and rmb pastes into the terminal&quot;.<p>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&#x27;t interact with this buffer.<p>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&#x27;s clipboard.<p>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.<p>It makes me feel bad about myself when I see people showing their tmux skills, because I can&#x27;t use it due to my demand of easily copying into and from the native clipboard.<p>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.<p>Both tools are really great, but I know that I&#x27;ll not be able to use them properly. Multiple mintty terminals are what I have to settle with.<p>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)?