Are there online resources for screen? It’s the canonical example of a tool with a name that makes it almost impossible to search for on the open internet.
GNU screen 5 proves it's still got game even after 37 years
GNU screen is included in most Linux distros, but newer, fancier tools such as tmux often outshine it. GNU screen 5.0.0 is the latest version of a tool that's been around since early 1987. This release has multiple tweaks to its (admittedly basic) user interface, much improved color handling, and better authentication support …
COMMENTS
-
-
-
-
Tuesday 3rd September 2024 16:06 GMT Anonymous Coward
Re: Ace2 - try here….
Well, yes, GNU can be, well, is a bit snooty at times, well, most of the time. It helps a lot if you know that the program is called "GNU Screen", as searching for that gives much better results. But of course GNU does have pages for its projects, including for screen: GNU Screen and there's even a PDF manual to be found. Curiously for 4.6.2 and not 5.0 as of this writing, but anyway.
My first port of call tends to be the manpage. Luckily, there are webified collections of those too. Like at linux.die.net: screen(1).
-
-
Wednesday 4th September 2024 03:56 GMT Anonymous Coward
Re: Ace2 - try here….
You mean you really want stackoverflow for quick cut-and-paste of probably-wrong but seems-to-work "solutions".
So far I've always had to stoop to RTFM to get my screen annoyances fixed.
Ideally, of course, people would contribute back their experiences and it'd result in a better manual, this being open source and all. Some software projects work exactly like this: Manpages, general handbook, FAQl, user-contributed how-to articles, even a wiki, searchable mailinglist archives and these days a webforum all under the same domain name. linux by its very nature is very fragmented, and emacs is made out of mostly user-generated quick annoyance fixes, but calling either the gold standard is maybe a bit much.
-
Tuesday 10th September 2024 20:49 GMT percolate
Re: Ace2 - try here….
"A Guide to Efficiently Using Irssi and Screen" (quadpoint) was my original introduction to GNU screen and it should serve most newcomers well due to its practical explanations. It might even be useful to those who are new to tmux and CLIs in understanding the important concepts.
I speculate that the main reason a lot of old software (for the sake of an example, I'll mention Debian & its wiki) is not as well documented as newer software (e.g. Arch) is due to the way Linux started and how people learned to use computers back then. A lot of what one might call old knowledge was built up "organically" through trial & error and cumulative experience (no cutting corners!). Even touch typing with correct form used to be taught at school, but no one thinks about the disadvantage of lacking that vital skill anymore when it comes to driving Linux with minimal resistance.
So there's not much remaining time/patience to write everything down when trying to just get something to work. Old users who already know how to do something won't need to write notes anymore, and younger users build new systems from scratch while also occasionally reinvent the wheel, but at least document it this time around.
Fast forward to modern times where good documentation practices are instilled into more users, along with easier accessibility and enthusiasm, and the tutorials practically write themselves.
-
-
-
Wednesday 4th September 2024 00:06 GMT Claptrap314
Re: Ace2 - try here….
Okay, so help me out here. In 1987, what search engine would you recommend I use to find this tool?
In that era, tools were named for what they did. The fact that it was called "screen" and not "scrn" WAS a major step in the direction of user-friendliness.
Seriously, get off your modernist moral high horse & get with the times. Open source was not, and is not, "unfriendly"--the fact that the devs are giving you hundreds or thousands (or tens of thousands) of hours of their own time FOR FREE is extremely friendly. Learn a bit of gratitude. Get some gorm. By then, you will hopefully have grown up enough to not be such a snot-nosed brat when someone gives you something FOR FREE.
-
-
-
Tuesday 3rd September 2024 16:21 GMT Anonymous Coward
Re: Android client?
Totally agree ... it's been the ultimate acme in most unsufferables of water-boarding tortures to search the web for: gnu screen for android (as in https://github.com/dove0rz/screen-android). Not sure if I'll ever recover the use of what little remains of me cuticles ...
-
-
Thursday 5th September 2024 00:44 GMT Michael Wojcik
It’s the canonical example of a tool with a name that makes it almost impossible to search for on the open internet.
Really? Searching for "gnu screen", with the quotes, worked Just Fine for me.
Personally, I've never needed more than the screen -h output, but there's plenty of material readily available if you just use a sensible search term.
-
-
-
-
-
Tuesday 3rd September 2024 16:28 GMT l8gravely
I still use it every single day, it's simply an amazing tool for what it does. Doesn't get in the way, you can manage it all from the keyboard and it makes my work be so less stressful. I've been using it for close on 30+ years now. I've looked at tmux, but the key bindings are hardcoded in my brain so I switched back. Tmux didn't give me much that I really needed.
Now to find a replacement for 'putty' which will auto-reconnect my SSH session(s) when they get disconnected. That would be really nice.
Tried mobaXterm, but it's just not my cup of tea. Expecially it's annoying re-opening the file share sidebar every time. I know I can disable it, I did for a while, but having the abiltiy to put two putty windows (100x48) side by side on my desktop is key, and mobaXterm just doesn't cut it because it takes too much screen realestate.
-
Tuesday 3rd September 2024 18:07 GMT Graham Cobb
Yep. I have screen currently running on at least 4 or 5 sessions on my computer as I type this: each one actually running on a different system - and each one with sessions logged into several different users on those systems. On most of my home systems I have a screen session running on each system, with sessions logged into my main user account, root, and any other accounts I want. I even ported screen to Tivo back in the day when I was doing active Tivo hacking.
But then I use command lines a lot.
-
-
Thursday 5th September 2024 09:11 GMT tblancher
Re: tiling
If you rely on GNU Screen (or any terminal multiplexer) for everything you do, it behooves you to add it to your shell's startup script (.bash_profile, .zshrc, etc.). You'll need to add logic to ensure you don't spawn a new session every time you launch the shell, open a new window/pane, or source your shell's startup file, but it can be done.
Also, since I use a terminal multiplexer everywhere, I prefer a terminal emulator which doesn't do a lot of internal tabs, split panes, scrollbars, etc.; I use the terminal multiplexer for that. Alacritty is one such terminal emulator; I'm not aware of any others that are like this.
And if you like to have two terminal emulators tiled side by side, you should also get a tiling window manager. But since I use a terminal multiplexer, I don't typically rely on the window manager to handle it, I just have a vertically split window in the terminal multiplexer. Thus, I never need more than one terminal emulator window open at any time.
-
-
-
Tuesday 3rd September 2024 19:11 GMT Anonymous Coward
There are options to Terminal
There are useful alternatives. I've been using iTerm2 for absolute ages, with a little tweak so any screen with high privileges automatically gets a red background (just a reminder that for the few cases sudo is not enough I have to be rather careful with what I type)..
-
-
Friday 6th September 2024 23:39 GMT _andrew
Re: There are options to Terminal
Multiple windows over one SSH connection: I never understood why this was useful, as there isn't a limit to the number of concurrent ssh sessions that you can have. I don't muck about with learning the escape sequences to do multiple panes on terminal interfaces: just open another terminal window and another ssh session.
-
-
-
Friday 6th September 2024 23:36 GMT _andrew
Alacritty is pretty nice
https://github.com/alacritty/alacritty/blob/master/README.md
I don't know whether "fastest" is true or even important. I like it because it does all of the right things and knows about modern "all-of-the-colours" escape sequences that lots of the cool kids seem to be using in their editor colour profiles.
Also a vote for mosh. Mosh is like an ssh upgrade mixed with screen. It uses ssh to establish a connection and then switches to its own protocol over UDP, which is why it doesn't care if the connection goes away and comes back later. It doesn't do tiling like screen, but it does do the server-side render+diff-update thing, so if you go away and come back you see the latest state of the remote process, which did not get paused on disconnect. This also means that you don't get scroll-back. Swings and roundabouts. Also: the predictive echo seems to work very nicely and does a good job of hiding line latency.
-
-
-
Tuesday 3rd September 2024 16:23 GMT Anonymous Coward
So what's the deal with immediately searching for something vaguely similar "written in rust!!1!"? What makes this upstart language elegible for special treatment but not others? Liam a fanboi? Pandering to teh fanbois? Brainwashed by the Rust Evangelism Strike Force? What?
Really now, I'd like to see listed at least see equivalents in fortran, lisp, cobol, or ada, for old times' sake, and equivalents in go, dart, hack, swift, java, or something similar for that big corporate flavour without which el reg just isn't true to form. Go on, at least pretend you're trying. Or, you know, let gnu screen have its new version day. It hasn't had one in, how long did you say it was again?
-
Tuesday 3rd September 2024 17:08 GMT Anonymous Coward
The last sentence is key: 'ubiquity'. When I have the choice I can pick something (usually tmux) I prefer, but it doesn't help when you're dropped in a situation where you need to get something figured out on a dubious network connection (often multiple hop tunnelling), and the VM/server only has screen.
This is especially true on computing clusters where the environment is locked down for maximum reproducibility, and you need all your time/focus on debugging a complex process. Losing the connection can mean having to requeue a long compute job before you can debug it again.
And yes, one should do all that is feasible to avoid those edge cases, but they do happen (usually on a Friday), and then that sober foresight does save the weekend.
That is not a judgement pro/con on features, but availability, e.g. I prefer zsh, but again, not always there.
Having the muscle memory of the 'if it's not there, it's because the world has ended' set of tools can be a lifesaver.
-
Tuesday 3rd September 2024 19:42 GMT Gary Stewart
Another advantage
of screen is that it is the only one that I am aware of that supports serial ports. Yes, I do use them on my NFS file server and router (yeah, old neckbeard here). The advantage of using serial ports for these is a much smaller memory and CPU usage footprint as well as power savings from not having a graphics card. The disadvantage of not having a graphics card is not being able to make BIOS/UEFI changes until one is installed. This is rarely a problem and is easily solved when needed. I use a Raspberry Pi 3 mounted on the back of an old 1680 x 1050 LCD monitor with a VESA mount along with a USB 2 to 8 serial port adapter for my terminal(s).
A really big problem I have with screen is that is does not handle going past the end of line at all, even when using \ to continue on the next line. Attempt to backspace after going beyond the end of line and it goes nuts getting completely lost. This is a real problem when long paths leave little room for any semi complicated command. A simple return will get it back on track it but it will attempt to execute the "command" you entered and it mangled. Not a good thing.
A lesser problem is when using vi it sets the screen size to 80 x 25 and I use 100 x 51 terminals for displaying 4 screen windows at once. Once set, it stays at 80 x 25 until I use the reset screen command. I have looked for a way to fix this but have not found one that works yet.
-
Tuesday 3rd September 2024 21:29 GMT Jamie Jones
Re: Another advantage
> A really big problem I have with screen is that is does not handle going past the end of line at all,
> even when using \ to continue on the next line. Attempt to backspace after going beyond the end
> of line and it goes nuts getting completely lost.
I've been using "screen" daily for over 20 years, and have never encountered that problem...
-
-
Tuesday 3rd September 2024 23:58 GMT Graham Cobb
Re: Another advantage
My experience is the same as Jamie's - similar length of time without seeing your problem. And I do (or did) use serial ports, connected to multiple TiVos. Using virtual terminals of various sizes and software.
Obvs it is a real problem in your use case but doesn't affect other people's use cases. No idea why.
-
Wednesday 4th September 2024 05:56 GMT Jamie Jones
Re: Another advantage
I wasn't implying you were lying, or doing anything wrong!
Just that maybe we could debug the problem together, swapping config files etc.
I have used serial ports, but not for many many years, so can't honestly say with authority that I have not had issues with them, not that I can recall any, but my memory on that may be faulty!
I'm willing to give it a go though. If you want to provide more specifics, I'll try and recreate it.
By the way, I've connected to all sorts of systems, but always run the screen host on FreeBSD. My guess is a termcap problem..
-
-
-
-
Tuesday 3rd September 2024 21:27 GMT TJ1
Back to front?
"Screen puts a rerouting layer between your terminal window and the computers you're talking to. So, before you connect, you run Screen, then connect"
>
"Screen puts a rerouting layer between your terminal window and the *process(es) you're using*. So, *after* you connect, you run Screen, then run your process(es)"
Surely if you want the remote processes to continue running on (accidental) disconnect, screen (tmux, and similar) are executed on the target where the processes are running. As in:
localhost -> ssh me@remotehost -> remotehost: "screen", "process-to-keep-running" ... 8-< disconnect
localhost -> ssh me@remotehost -> remotehost: "screen -r" *happy-face*
-
Wednesday 4th September 2024 00:07 GMT Graham Cobb
Re: Back to front?
Both are useful.
I often create an Xterm on my workstation, run screen in that, and connect to three or 4 different hosts when working on a task that is split across multiple servers. That way these sessions survive if my workstation reboots, and I am switching between the different hosts for the task in a single VT.
For my main home systems, though, I create an Xterm running screen on my workstation for each system and then create several terminal sessions on that system, logged in as various users (my main account, root, some special users, etc).
-
-
Wednesday 4th September 2024 10:43 GMT Spamfast
mux me baby
I fell in love with screen but we split up when I started dating tmux. Both are excellent but tmux is a bit more Spamfast/idiot friendly. And yes, tmux can do TTYs as well. Back when my interface really was VT100 serial terminals I used Emacs to achieve similar multitasking minus the restart ability. All great tools.
As my T-shirt says - Real men use the command line. (Also women and small blue furry creatures from Alpha Centuri.)
-
Wednesday 4th September 2024 17:48 GMT Henry Wertz 1
I use it daily.
So in command line linux, you can hit control-alt-F1 through F7 (usually. this is distro specific) to get 7 text consoles? Screen lets you do that,.
I use it daily. One konsole to switch between numerous text screens. (so i can hit control-a 0 to go to one with top running, control-a n and control-a p go to next and previous screens, etc.) Ssh in somewhere and have more than one screen. and if connection drops, ssh back in and resume my screen session.
I actually bought a surplus VT102 many years ago (when i was in high school) and had it in the basement -- my keyboard would keep my parents up so i could go down there and use the VT102 (hooked with a long serial cable) to continue using my computer. This was mid 1990s so I did not have a large amount of graphical apps I wanted to use, my 4MB system didn't have enough RAM to run most of them anyway.
-
Thursday 5th September 2024 09:11 GMT tblancher
Re: GNU screen use case
I think the use case you described for the uninitiated is a bit muddy and unclear. My first reaction is that you had it backwards, you connect to the remote system first and then run Screen (to use your disambiguation) there, not locally. That way if your connection dies or you shut down your local terminal emulator, you can reconnect to the remote machine and pick up where you left off.
I think you used the word "connect" ambiguously, or at least too soon. I think it would have served readers better had you mentioned sessions first, and used the word "attach" instead.
Screen (or tmux, etc.) can launch and attach to a session that can optionally be named. The session typically runs your preferred interactive shell, but it can be directed to run any CLI program. You can then detach from this session, close your terminal emulator, open a new, possibly different terminal emulator, or even connect remotely from another machine, and reattach to this session without losing your place (the program running in the session has no idea that anything happened). The only thing that would kill the session would be a reboot, or a signal that tells the program running in the session to exit. Having the ability to add windows and panes to a session allows you to run more than one CLI program within the session; detach and reattach from the session, and everything in it keeps on running.
One bonus where I really exercised the power of GNU Screen was when I was doing tech support for a company that produced hardware for Linux. We had out of tree driver modules that the end user needed to compile to use the hardware, and many times a week I'd have to request that they share SSH credentials so I could log in and figure out what they were doing wrong. To instill trust I'd always fire up Screen and have both of us attach to the same session, so they could either show me what they were doing, or let me drive and they could see everything I was doing. If they were really paranoid I would always recommend they let me connect with an unprivileged account, and then they could escalate my privileges without disclosing their root password.
Nowadays I don't use GNU Screen anymore, for a number of different reasons. First, I didn't like that by default there is no visible indication that you're in a Screen session. Also, its default prefix key conflicts with the emacs beginning of line key (I think it's really bizarre that a pair of GNU programs has such an incompatibility by default); this is especially apparent if you use emacs mode in your shell. I also found that the Screen configuration is rather ad hoc and not very orthogonal. It also didn't seem very scriptable the last time I used it. Another reason which is quite anecdotal: I had a VP of engineering forbid me from using Screen on some Linux servers since he thought it was consuming too many resources. I never could disprove that, but it made managing those servers that much more difficult. I don't know if GNU Screen 5 addresses any of these issues, but it's already too late.
Now I use tmux for everything. Because it is so scriptable, and its configuration is much more orthogonal, I have it integrated into my .zshrc everywhere, on Linux and macOS. I have a local tmux server with multiple named sessions (one session for each host I regularly connect to over SSH), plus a remote tmux server on each host, with various named sessions specific for that host. So yes, I run nested tmux sessions all the time, against conventional wisdom. I don't think I'll ever go back to Screen, tmux is so embedded in my workflow it would be too much effort to change it back.