[HN Gopher] GNU Screen 5.0 Released
___________________________________________________________________
GNU Screen 5.0 Released
Author : jrepinc
Score : 199 points
Date : 2024-08-29 14:09 UTC (8 hours ago)
(HTM) web link (savannah.gnu.org)
(TXT) w3m dump (savannah.gnu.org)
| freedomben wrote:
| 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
| mdaniel wrote:
| > 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
| mrj wrote:
| Yeah maddening! But you can remap it. I use this in my
| .screenrc to make it C-f:
|
| escape ^Ff
| Jtsummers wrote:
| 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.
| qup wrote:
| C-Space here
| foobarian wrote:
| C-t for me
| stragulus wrote:
| 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.
| khc wrote:
| I map mine to C^] which I find to be a good balance between
| easy to type and not conflicting with other tools
| sam_lowry_ wrote:
| Two hands gesture? No way!
| bicolao wrote:
| As someone who also uses emacs, I type C-a a so often that
| sometimes I do the same in emacs and it leaves an extra a.
| It's quite rare though.
| freedomben wrote:
| C-a C-a definitely annoyed me at first, but I got used to it
| and now I don't mind it at all.
| rwmj wrote:
| I remap the screen escape key to Shift-Ctrl-^:
| escape ^^^
| trallnag wrote:
| I wonder how many people are using the default b key binding in
| tmux
| entropie wrote:
| No emacs user.
|
| I use p in screen and tmux as prefix key. I usually prefer
| tmux.
| sorrythanks wrote:
| Your use of p surprises me if you don't use b for emacs
| reasons! How do you go up a line!?
| entropie wrote:
| 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.
| setopt wrote:
| I dropped the prefix entirely:
| https://github.com/jabirali/tmux-tilish
| 331c8c71 wrote:
| I do.
| vindex10 wrote:
| I usually use ctrl+a locally but ctrl+b remotely, so they
| don't clash when nested.
| lanstin wrote:
| 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 :)
| e-max wrote:
| 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.
| eikenberry wrote:
| 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.
| susam wrote:
| > 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.
|
| Here is my tiny .tmux.conf:
| https://github.com/susam/dotfiles/blob/main/.tmux.conf
| __david__ wrote:
| 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).
| aeonik wrote:
| 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.
| Jtsummers wrote:
| 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.
| freedomben wrote:
| Yes, this is exactly why I switched as well.
|
| 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.
| ho_schi wrote:
| 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.
| mhitza wrote:
| > 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.
| ho_schi wrote:
| Thanks. I don't need that features but I see the use case
| for others.
| boltzmann-brain wrote:
| > Having a modem is a pretty handy thing built into it.
|
| in what way?
| mm0lqf wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| vmladenov wrote:
| Ha, I have only ever used screen for serial comms and
| only learned about Minicom from this thread
| stragulus wrote:
| 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.
| radicality wrote:
| 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.
| riddley wrote:
| 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.
| kzrdude wrote:
| Truecolor finally being released is big
| thanatos519 wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| int_19h wrote:
| 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.
| josephcsible wrote:
| > 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".
| lloeki wrote:
| 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.
| Arnavion wrote:
| 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.
| rauhl wrote:
| > 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.
| rauhl wrote:
| > Ctrl+a from my cold dead fingers
|
| 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).
| jmclnx wrote:
| Very nice, will need to give it a try. For my use there is no
| difference wuth screen vs tmux except for attaching.
|
| 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.
|
| One thing I do like, screen is a lighter in resource usage these
| days.
| chasil wrote:
| I notice that Screen has moved into EPEL, while tmux is in baseos
| for the RHEL family.
|
| Is there anything compelling in the latest release?
| ho_schi wrote:
| Finally :)
|
| I'm waiting for a year that we don't have to push _Escape_ twice
| in Vim /Neovim. Some mouse emulation was catching it.
|
| https://savannah.gnu.org/bugs/?57748
| https://superuser.com/questions/1675761/why-does-gnu-screen-...
|
| I should write the developers a note with thanks :)
| kzrdude wrote:
| 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.
| anthk wrote:
| On TMUX, there was a setting to avoid the lag for vis/vim.
| throw0101d wrote:
| To anyone to perhaps who has used both a lot:
|
| * Are there particular pros and cons to using _screen_ or _tmux_?
|
| (I'm generally on macOS for work, but never really go into using
| iTerm2, so that integration isn't a big thing for me personally.)
|
| Edit: I mean why use one over the other. I generally use
| something on the destination host I'm SSHing to in case the
| network goes sideways.
| kstrauser wrote:
| In that case, try Zellij. I gave it a shot the last time it
| made the rounds on HN and instantly loved it.
|
| Killer feature: mouse scrolling works out of the box.
| sundarurfriend wrote:
| 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.
| kstrauser wrote:
| 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.
| nolist_policy wrote:
| Screen can connect to serial ports. screen
| /dev/ttyUSB0 9600
| thiht wrote:
| What does it do exactly?
| d4rti wrote:
| It's been a while but I used this with a USB to serial and
| a console cable for accessing Cisco switches/routers
| console.
| pak9rabid wrote:
| 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.
| pwg wrote:
| > 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.
| filloutform wrote:
| tmux does all that
| Izkata wrote:
| One advantage of knowing screen, it's likely already installed
| on whatever remote machine you're connecting to.
| throw0101d wrote:
| IIRC: RHEL9 no longer has screen (EPEL-only), and only has
| tmux.
| WhatIsDukkha wrote:
| 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.
|
| Hard with screen and easy with tmux.
| panki27 wrote:
| 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).
| ur-whale wrote:
| > with some setup, of course
|
| Care to share the config ?
|
| [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 ?
| samgranieri wrote:
| I started with screen and Terminal.app, then I switched to tmux
| and iTerm. Now i"m on wezterm and zellij. Works great!
|
| Still, I'm happy to see work on screen continuing.
| paranoidxprod wrote:
| 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.
| samgranieri wrote:
| I use zellij's session resurrection all the time, it saves
| me time. It's kind of like tmuxinator.
|
| I'm not sure if zellij can do that, and coming from tmux,
| zellij was an easy change.
| mickeyp wrote:
| Screen, tmux, et al. are great.
|
| 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.
| xedrac wrote:
| Obigatory Emacs video:
| https://www.youtube.com/watch?v=urcL86UpqZc
| zelphirkalt wrote:
| Somehow I knew what video that would be, before clicking the
| link.
| znpy wrote:
| 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.
| setopt wrote:
| 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.
| setopt wrote:
| > 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.
| cherryteastain wrote:
| 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.
| pama wrote:
| 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.
| iLemming wrote:
| vterm works nicely. My only gripe that Evil support in vterm
| isn't great, but that's irrelevant in this context.
| helmsb wrote:
| But the AI generated article from the front page yesterday said I
| shouldn't use Screens anymore... /s
| neilv wrote:
| 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`.
| ho_schi wrote:
| 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".
| kzrdude wrote:
| Screen has multiuser features, two people can share the same
| screen session
| sam_lowry_ wrote:
| screen -x
| ho_schi wrote:
| This rocks. It is a superpower and I love it :)
| thanatos519 wrote:
| It's such a great feature and even has ACLs.
|
| 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.
| neilv wrote:
| 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.
| nextos wrote:
| 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.
| neilv wrote:
| `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.
| nextos wrote:
| I know, this is why I said it's not perfect.
| MajesticHobo2 wrote:
| 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...
| __david__ wrote:
| 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?
| p1mrx wrote:
| I wish they'd do something about
| https://savannah.gnu.org/bugs/?63341, where switching to "copy
| mode" blocks the process without warning.
| elashri wrote:
| 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.
| ffsm8 wrote:
| 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.
| teroshan wrote:
| > 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.
| thanatos519 wrote:
| WTF! That was one of my favourite features!!!!
| mistrial9 wrote:
| humor ? it was removed 8 years ago?
| therein wrote:
| So the latest on the stable Debian repo?
| bravetraveler wrote:
| The next Ubuntu LTS, once it hits Debian unstable/ages a
| little, lol. I kid - it's overstated.
| rwmj wrote:
| https://xkcd.com/1172/
| PortableCode wrote:
| looks like this command was removed in 2015, so, almost 9 years
| ago, and now they cleaned up the documentation
|
| https://git.savannah.gnu.org/cgit/screen.git/commit/?id=9109...
| ajdude wrote:
| The day sudo removes the `insults` feature will be a sad day
| for me.
| senko wrote:
| 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.
|
| Congrats on the release!
| qwertox wrote:
| 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)?
___________________________________________________________________
(page generated 2024-08-29 23:01 UTC)