Live data from Hacker News

GNU Screen 5.0 Released

savannah.gnu.org

91–100 of 126 posts

Re: GNU Screen 5.0 Released

#92
post #75

Earlier quoted context omitted.

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.

C-Space here

C-t for me

Re: GNU Screen 5.0 Released

#93

> Removed commands: - nethack https://www.gnu.org/software/screen/manual/html_node/Nethack... > 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.

WTF! That was one of my favourite features!!!!

https://xkcd.com/1172/

Re: GNU Screen 5.0 Released

#94
post #8

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…

> Ctrl+a from my cold dead fingers As someone who uses `set -o emacs` I cannot possibly imagine pressing C-a C-a to go to the beginning of the line Also, as an iTerm2 user: the integration with tmux control mode (tmux -CC) is just amazing for the way I use tmux

I remap the screen escape key to Shift-Ctrl-^:

  escape ^^^

Re: GNU Screen 5.0 Released

#95

Earlier quoted context omitted.

I'm looking forward to trying this indeed. 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 configu…

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.

Re: GNU Screen 5.0 Released

#96
post #45

Earlier quoted context omitted.

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.

Ha, I have only ever used screen for serial comms and only learned about Minicom from this thread

Re: GNU Screen 5.0 Released

#97
post #39
post #23

Earlier quoted context omitted.

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.

Re: GNU Screen 5.0 Released

#98
post #97
post #39

Earlier quoted context omitted.

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…

`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.

Re: GNU Screen 5.0 Released

#99
post #19

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…

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?

Re: GNU Screen 5.0 Released

#100
post #98
post #97

Earlier quoted context omitted.

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…

`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 know, this is why I said it's not perfect.
Post reply on HN