Claude Code Masterkurs – KI-gestuetztes Programmieren lernen mit Anthropics Coding-Agent

Lektion 31: screen - Klassischer Terminal Multiplexer

Tool-Lektion | 35 Minuten

GNU screen ist der klassische Terminal-Multiplexer, der seit 1987 existiert und auf nahezu jedem Unix-System verfügbar ist. Als Vorgänger von tmux bietet screen robuste Session-Persistenz und Mult

Lernziele

Lektion 31: screen - Klassischer Terminal Multiplexer

Berechtigung

GNU screen ist der klassische Terminal-Multiplexer, der seit 1987 existiert und auf nahezu jedem Unix-System verfügbar ist. Als Vorgänger von tmux bietet screen robuste Session-Persistenz und Multi-Window-Management, besonders wertvoll für Legacy-Systeme und Umgebungen, wo moderne Alternativen nicht verfügbar sind.

Was ist screen?

screen ist ein Terminal-Multiplexer mit folgenden Eigenschaften:

Warum screen für Claude Code?

🚀 Claude Code Relevanz: screen ist auf praktisch jedem Server vorinstalliert und ermoeglicht es, Claude Code Aufgaben in persistenten Sessions laufen zu lassen -- selbst bei SSH-Abbruechen geht keine Arbeit verloren.

Zwecke

Primäre Anwendungsfälle

Typische Workflows

Verwendung

Installation

screen ist auf den meisten Unix-Systemen bereits vorinstalliert. Falls nicht, kann es ueber den jeweiligen Paketmanager nachinstalliert werden:

# macOS
brew install screen

# Ubuntu/Debian
apt install screen

# Arch Linux
pacman -S screen

# CentOS/RHEL
yum install screen

# Meist bereits vorinstalliert prüfen:
which screen
screen --version

Grundlegende Verwendung

Die grundlegenden Befehle fuer screen: Sessions erstellen, auflisten und wieder verbinden. Mit -S gibst du der Session einen Namen, mit -r verbindest du dich wieder:

# Neue Session starten
screen

# Named Session starten
screen -S my-session

# Session im Background starten
screen -dmS background-task

# Aktive Sessions auflisten
screen -ls

# An Session anhängen
screen -r my-session

# An Session anhängen (forciert)
screen -x my-session  # Auch wenn jemand anderes attached ist

# Session löschen (töten)
screen -X -S my-session quit

# Von Session detachen
# In screen: Ctrl+a d

Wichtigste Tastenkombinationen

⚠️ Warnung: Alle screen-Kommandos beginnen mit Ctrl+a -- verwechsle das nicht mit dem Bash-Shortcut Ctrl+a (Zeilenanfang). Innerhalb von screen ist dieser Prefix reserviert.

WICHTIG: Alle screen-Kommandos beginnen mit dem Prefix Ctrl+a

Session Management:

Mit Detach verlaesst du die Session, ohne sie zu beenden. Die Prozesse laufen weiter und du kannst dich spaeter wieder verbinden:

Ctrl+a d         Detach von Session
Ctrl+a D D       Detach und Logout
Ctrl+a \         Alle Windows killen und quit
Ctrl+a :quit     Session beenden

Window Management:

Windows sind virtuelle Terminals innerhalb einer Session. Du kannst mehrere Windows erstellen und zwischen ihnen mit Nummern oder der Window-Liste wechseln:

Ctrl+a c         Neues Window erstellen
Ctrl+a n         Nächstes Window
Ctrl+a p         Vorheriges Window
Ctrl+a 0-9       Zu Window 0-9 springen
Ctrl+a "         Liste aller Windows
Ctrl+a k         Aktuelles Window killen
Ctrl+a A         Window umbenennen

Window Splitting:

Splits teilen das Terminal-Fenster in mehrere sichtbare Bereiche. Beachte: Nach einem Split musst du mit Tab zum neuen Bereich wechseln und dort ein Window oeffnen:

Ctrl+a S         Horizontal split
Ctrl+a |         Vertikal split (wenn patch vorhanden)
Ctrl+a Tab       Zwischen Splits wechseln
Ctrl+a Q         Alle Splits außer aktuellem schließen
Ctrl+a X         Aktuellen Split schließen

Copy Mode:

Der Copy Mode erlaubt Scrollen und Textkopieren. Navigation funktioniert mit Vi-Keybindings. Mit Space startest du die Selektion, mit Enter kopierst du:

Ctrl+a [         Copy Mode aktivieren (vi-mode)
Ctrl+a Esc       Alternative: Copy Mode aktivieren

# Im Copy Mode:
h,j,k,l         Navigation (vi-style)
Space           Selektion start/end
Enter           Kopieren und Mode verlassen
Ctrl+a ]        Paste kopierter Text

Hilfreich:

Diese Shortcuts sind die schnellen Helfer im screen-Alltag. Mit Ctrl+a ? oeffnest du die eingebaute Hilfe, die alle verfuegbaren Keybindings auflistet. Der Command Mode (Ctrl+a :) erlaubt das Ausfuehren beliebiger screen-Befehle, und Ctrl+a Ctrl+a wechselt blitzschnell zwischen den letzten zwei verwendeten Windows hin und her. Besonders der letztgenannte Shortcut ist im Alltag unverzichtbar, wenn du haeufig zwischen Editor und Terminal wechselst.

Ctrl+a ?         Hilfe anzeigen
Ctrl+a :         Command Mode
Ctrl+a Ctrl+a    Zwischen letzten zwei Windows wechseln

Konfiguration

screen liest beim Start die Datei ~/.screenrc. Hier koennen Standard-Einstellungen wie Scrollback-Groesse, Status-Leiste und Keybindings definiert werden:

# ~/.screenrc

# Startup-Message deaktivieren
startup_message off

# Scrollback Buffer (Zeilen)
defscrollback 10000

# Automatisches Detach bei Hangup
autodetach on

# Visual Bell statt Audio
vbell on
vbell_msg "   -- Bell --   "

# Status-Line am unteren Rand
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %m-%d %{W}%c %{g}]'

# Standard Shell
shell -$SHELL

# Encoding UTF-8
defutf8 on

# Mouse Scrolling (wenn unterstützt)
termcapinfo xterm* ti@:te@

# Alternativen Prefix (optional, statt Ctrl+a)
# escape ^Bb  # Wechselt zu Ctrl+b

# Window-Titel automatisch
shelltitle "$ |bash"

# Key-Bindings anpassen
bind c screen 1  # Neue Windows bei 1 starten, nicht 0
bind 0 select 10

# Quick Splitting
bind s split
bind v split -v  # Wenn patch vorhanden

# Reload config
bind r source $HOME/.screenrc

# Logging aktivieren
logfile /tmp/screen-%Y%m%d-%n.log
💡 Tipp: Nutze screen -dRR session-name um eine Session anzulegen oder automatisch wieder zu verbinden -- das spart dir das separate Auflisten und Attachen.

Session Management Advanced

Fortgeschrittene Session-Verwaltung: Sessions koennen mit Befehlen gestartet, geteilt oder automatisch wiederhergestellt werden. -dRR ist besonders nuetzlich -- es erstellt die Session falls noetig oder verbindet sich automatisch:

# Session starten mit Command
screen -dmS build bash -c "make all"

# An Session anhängen oder neu erstellen
screen -dRR session-name

# Multi-Display Session Sharing
# Terminal 1:
screen -S shared

# Terminal 2 (oder anderer User):
screen -x shared  # Beide sehen gleichen Output

# Nested screen vermeiden
if [ -z "$STY" ]; then
    screen -dRR main
fi

# Session-Name in Terminal-Titel
echo -ne "\033]0;screen: $(echo $STY | cut -d. -f2-)\007"

Regions und Layouts

Screen unterstuetzt Split-Regions, mit denen du mehrere Windows gleichzeitig sehen kannst. Der Workflow erfordert mehrere Schritte: Splitten, zum neuen Split wechseln, und dort ein Window zuweisen:

# Screen Split Workflow:
screen                   # Starten
Ctrl+a S                # Horizontal Split
Ctrl+a Tab              # Zu neuem Split wechseln
Ctrl+a c                # Neues Window in Split
Ctrl+a S                # Noch ein Split
Ctrl+a Tab              # Wechseln
Ctrl+a c                # Weiteres Window

# Layout speichern (in .screenrc):
layout new coding
split
focus
resize -5
split -v
focus
select 1
focus
select 2
layout save coding

Best Practices

Die folgenden Tipps helfen dir, screen produktiv einzusetzen und haeufige Stolperfallen zu vermeiden.

. Session-Namenskonvention

Konsistente Namen erleichtern das Wiederfinden von Sessions. Kombiniere Projektname und Aufgabe, damit du bei screen -ls sofort siehst, was wo laeuft:

# Strukturierte Namen
screen -S <project>-<task>
screen -S webapp-dev
screen -S db-migration
screen -S logs-monitoring

# Mit Datum für historische Referenz
screen -S deploy-$(date +%Y%m%d)

. .screenrc für verschiedene Profile

Mit separaten Config-Dateien kannst du verschiedene Arbeitsumgebungen definieren, die beim Start automatisch Windows mit vordefinierten Programmen oeffnen:

# ~/.screenrc.dev - Development Profile
source ~/.screenrc
screen -t Editor 0 vim
screen -t Shell 1
screen -t Server 2 npm run dev

# Verwenden mit:
screen -c ~/.screenrc.dev -S dev-session

. Automatischer Reconnect

Dieses Shell-Snippet verbindet dich beim SSH-Login automatisch mit einer bestehenden Session, sodass du nie versehentlich ohne Multiplexer arbeitest:

# In ~/.bashrc oder ~/.zshrc
# Automatisch an screen anhängen beim SSH-Login
if [ -n "$SSH_CLIENT" ] && [ -z "$STY" ]; then
    screen -dRR ssh-session
fi

. Screen als Service-Monitor

Mehrere Services koennen in separaten Windows einer einzelnen Session laufen. Das ermoeglicht schnelles Umschalten zwischen Logs, Servern und Datenbanken:

# Mehrere Services in einer Session starten
screen -dmS services

screen -S services -X screen -t "Web" 0 python -m http.server
screen -S services -X screen -t "API" 1 node server.js
screen -S services -X screen -t "DB" 2 mongod
screen -S services -X screen -t "Logs" 3 tail -f /var/log/app.log

# Alle Services monitoren:
screen -r services
🚀 Beispiel: Mit screen -dmS build bash -c "make all" startest du einen Build-Prozess im Hintergrund. Du kannst ihn spaeter mit screen -r build inspizieren -- perfekt fuer lange Compilations.

. Logging aktivieren

Logging zeichnet den gesamten Terminal-Output einer Session auf. Das ist besonders wertvoll bei langen Deployments oder Migrationen, deren Output man spaeter analysieren moechte:

# In laufender Session:
Ctrl+a H     # Logging toggle

# Per Default in .screenrc:
# Alle Windows loggen
deflog on
logfile /var/log/screen/screen-%Y%m%d-%n-%t.log

# Oder per Command-Line:
screen -L -dmS logged-session

. Screen mit SSH ProxyJump

Bei Multi-Hop-SSH-Verbindungen schuetzt screen vor Datenverlust bei Verbindungsabbruechen. Starte screen auf dem Jumphost, damit deine Arbeit auch bei Netzwerkproblemen erhalten bleibt:

# Für Multi-Hop SSH
ssh jumphost
screen -dRR work
ssh targetserver
# Arbeit erledigen...
# Verbindung bricht ab -> kein Problem

# Wieder verbinden:
ssh jumphost
screen -r work
# Alles noch da!

Beispiele

Die folgenden Beispiele decken typische screen-Anwendungen ab -- von der einfachen Remote-Session bis zur automatisierten Multi-Server-Ueberwachung.

Beispiel 1: Basic Remote Session

Der haeufigste Anwendungsfall: Einen langlebigen Prozess auf einem Remote-Server starten und spaeter wieder darauf zugreifen:

# SSH in Server
ssh user@remote-server

# Screen Session starten
screen -S work

# Langläufigen Task starten
./long-running-script.sh

# Detach
Ctrl+a d

# SSH schließen
exit

# Später: Wieder verbinden
ssh user@remote-server
screen -r work
# Script läuft noch!

Beispiel 2: Multi-Window Development

Dieser Workflow zeigt, wie du mehrere virtuelle Terminals innerhalb einer einzigen screen-Session organisierst. Jedes Window bekommt eine eigene Aufgabe: Editor, Compiler, Tests und Git. Das ist besonders nuetzlich, wenn du keinen modernen Terminal-Multiplexer mit Splits zur Verfuegung hast und trotzdem mehrere Aufgaben parallel verwalten willst. Du wechselst zwischen den Windows mit Ctrl+a gefolgt von der Window-Nummer, was nach kurzer Eingewoehnung sehr schnell geht. Stell dir vor, du arbeitest an einem Rust-Projekt: Im Editor schreibst du Code, der Compiler im Watch-Modus zeigt sofort Fehler, die Tests laufen parallel und lazygit gibt dir den Git-Ueberblick. Im Terminal siehst du immer nur ein Window, aber kannst in Sekundenbruchteilen zwischen allen wechseln.

# Development Session starten
screen -S dev

# Windows erstellen:
Ctrl+a c    # Window 0: Editor
vim src/main.rs

Ctrl+a c    # Window 1: Compiler
cargo watch -x run

Ctrl+a c    # Window 2: Tests
cargo watch -x test

Ctrl+a c    # Window 3: Git
lazygit

# Zwischen Windows navigieren:
Ctrl+a 0    # Editor
Ctrl+a 1    # Compiler
Ctrl+a 2    # Tests
Ctrl+a 3    # Git

Beispiel 3: Split-Screen Layout

Screen unterstuetzt horizontale Splits, mit denen du zwei Windows gleichzeitig sehen kannst. Das ist hilfreich, wenn du gleichzeitig Code editieren und Tests beobachten willst, ohne zwischen Windows wechseln zu muessen. Beachte, dass du nach dem Split erst mit Tab zum neuen Bereich wechseln und dort ein neues Window erstellen musst -- ein haeufiger Stolperstein fuer Einsteiger. In diesem Beispiel editierst du im oberen Split eine JavaScript-Datei, waehrend im unteren Split die Tests im Watch-Modus laufen. So siehst du sofort, ob deine Aenderungen Tests brechen. Die vertikale Split-Funktion ist erst ab screen Version 4.2.0 verfuegbar.

# Screen mit Splits
screen -S splitdev

# Layout aufbauen:
Ctrl+a S       # Horizontal split
Ctrl+a Tab     # Zu unterem Split
Ctrl+a c       # Neues Window im unteren Split
# Tests laufen lassen
npm test -- --watch

Ctrl+a Tab     # Zurück zu oberem Split
# Code editieren
vim index.js

# Zwischen Splits: Ctrl+a Tab

Beispiel 4: Shared Session fuer Pair Programming

Screen ermoeglicht es zwei Personen, die gleiche Terminal-Session gleichzeitig zu sehen und zu steuern. Das funktioniert, indem beide Nutzer per SSH auf die gleiche Maschine zugreifen und sich mit screen -x an die gleiche Session anhaengen. Beide sehen jeden Tastendruck in Echtzeit -- perfekt fuer Remote Pair Programming, Debugging-Sessions mit Kollegen oder das Einarbeiten neuer Teammitglieder. Im Vergleich zu Screen-Sharing-Tools wie Zoom gibt es praktisch keine Latenz, da beide direkt mit dem gleichen Prozess verbunden sind. Beachte, dass der Guest SSH-Zugriff auf die Host-Maschine benoetigt und beide Nutzer die gleichen Berechtigungen auf die screen-Session haben muessen.

# User 1 (Host):
screen -S pair-session
# Programmieren...

# User 2 (Guest):
ssh user1@host-machine
screen -x pair-session

# Beide sehen und kontrollieren die gleiche Session!
# Perfekt für:
# - Remote Pair Programming
# - Debugging mit Kollegen
# - Training/Mentoring
# - Emergency Support

Beispiel 5: Server Deployment Workflow

Ein Deployment erfordert mehrere parallele Aktivitaeten: Backup erstellen, die Anwendung deployen, Logs ueberwachen und Systemressourcen pruefen. Mit screen kannst du fuer jeden Schritt ein eigenes benanntes Window erstellen und zwischen ihnen wechseln. Das ist besonders wichtig, weil ein Deployment auf einem Produktionsserver nicht abbrechen darf -- wenn die SSH-Verbindung waehrend des Deployments abbricht, laeuft die screen-Session weiter. In diesem Beispiel erstellst du vier Windows: eines fuer das Datenbank-Backup, eines fuer das eigentliche Deployment, eines fuer Live-Log-Monitoring und eines fuer htop zur System-Ueberwachung. Mit Ctrl+a und der Anzeige der Window-Liste behältst du den Ueberblick.

# Deployment Session
screen -S deploy

# Window 0: Backup erstellen
Ctrl+a A    # Window benennen: "backup"
./backup-database.sh

# Window 1: Deployment
Ctrl+a c
Ctrl+a A    # Benennen: "deploy"
./deploy-application.sh

# Window 2: Log monitoring
Ctrl+a c
Ctrl+a A    # Benennen: "logs"
tail -f /var/log/application.log

# Window 3: System monitoring
Ctrl+a c
Ctrl+a A    # Benennen: "htop"
htop

# Window-Liste ansehen:
Ctrl+a "

Beispiel 6: Serial Console Access

Screen kann sich ueber serielle Schnittstellen mit Hardware verbinden -- ein Feature, das weder tmux noch zellij bieten. Das ist unverzichtbar bei Embedded Development, wenn du mit Microcontrollern, Routern oder anderen Geraeten kommunizieren musst. Du gibst die serielle Schnittstelle (z.B. /dev/ttyUSB0) und die Baud-Rate (z.B. 115200) als Parameter an, und screen oeffnet eine interaktive Verbindung. Stell dir vor, du programmierst einen Arduino: Der serielle Output des Geraets erscheint direkt in screen, und du kannst Befehle zuruecksenden. Zum Beenden der seriellen Verbindung nutzt du Ctrl+a k, um das Window zu schliessen. Beachte, dass du moeglicherweise in der dialout-Gruppe sein musst, um auf serielle Ports zugreifen zu koennen.

# Verbindung zu Hardware via Serial Port
screen /dev/ttyUSB0 115200

# Für Embedded Development:
screen /dev/ttyACM0 9600

# Disconnect: Ctrl+a k (kill window)
💡 Tipp: Aktiviere Logging mit Ctrl+a H in wichtigen Sessions -- so kannst du den gesamten Output spaeter nachvollziehen, selbst wenn du nicht live zugesehen hast.

Beispiel 7: Long-Running Build

Lange Build-Prozesse sind der klassische Anwendungsfall fuer screen. Wenn du auf einem Build-Server ein Projekt kompilierst, das Stunden dauern kann (z.B. den Linux-Kernel oder ein grosses C++-Projekt), willst du nicht die gesamte Zeit die SSH-Verbindung offen halten. Du startest screen, beginnst den Build, detachst mit Ctrl+a d und schliesst die SSH-Verbindung. Die Kompilierung laeuft im Hintergrund weiter. Spaeter verbindest du dich erneut per SSH und schaust mit screen -r build nach dem Status. Falls der Build abgeschlossen ist, siehst du die Ergebnis-Ausgabe; falls er noch laeuft, kannst du den Fortschritt beobachten. Das spart nicht nur Nerven, sondern auch Bandbreite.

# SSH in Build-Server
ssh build-server

# Screen starten
screen -S build

# Build starten
./configure
make -j8  # Kompiliert Stunden...

# Detach und SSH schließen
Ctrl+a d
exit

# Abends überprüfen:
ssh build-server
screen -r build
# Build Status prüfen

Beispiel 8: Database Migration mit Logging

Datenbank-Migrationen sind kritische Operationen, die nicht unterbrochen werden duerfen und deren Output dokumentiert werden muss. Mit dem -L-Flag aktivierst du automatisches Logging, sodass der gesamte Terminal-Output in eine screenlog-Datei geschrieben wird. Das ist besonders wertvoll, wenn eine Migration fehlschlaegt und du spaeter analysieren musst, an welcher Stelle der Fehler aufgetreten ist. Stell dir vor, du migrierst eine Datenbank mit Millionen von Eintraegen: Die Migration dauert Stunden, und du willst den Fortschritt von einem anderen Rechner aus verfolgen. Mit tail -f screenlog.0 kannst du das Log in Echtzeit von aussen lesen, ohne die screen-Session selbst zu oeffnen. Nach Abschluss der Migration hast du eine vollstaendige Dokumentation des gesamten Prozesses.

# Screen mit Logging
screen -L -S migration

# Migration starten (könnte Stunden dauern)
psql -d database -f migration.sql

# Detach
Ctrl+a d

# Log-File wird geschrieben: screenlog.0
# Von außen monitoren:
tail -f screenlog.0

Beispiel 9: Multi-Server Monitoring

Dieses Script erstellt ein Monitoring-Dashboard, das die Logs mehrerer Server in separaten screen-Windows zusammenfasst. Jedes Window zeigt den Live-Log-Stream eines anderen Servers: Web-Server-Zugriffslogs, Datenbank-Logs und Redis-Monitor. Du wechselst mit Ctrl+a und der Window-Nummer zwischen den Servern und hast so den Ueberblick ueber deine gesamte Infrastruktur in einer einzigen screen-Session. Das ist besonders wertvoll bei der Fehlersuche, wenn du korrelierte Events auf verschiedenen Servern beobachten musst. Stell dir vor, ein API-Fehler tritt auf: Du schaust im Web-Window den Request, im DB-Window die Queries und im Cache-Window die Redis-Operationen. Das Script kannst du auch als Cronjob starten, damit das Monitoring-Dashboard nach einem Server-Neustart automatisch verfuegbar ist.

#!/bin/bash
# ~/scripts/monitor-servers.sh

# Screen Session mit Windows für mehrere Server
screen -dmS monitoring

screen -S monitoring -X screen -t "Web1" 0 ssh web1 'tail -f /var/log/nginx/access.log'
screen -S monitoring -X screen -t "Web2" 1 ssh web2 'tail -f /var/log/nginx/access.log'
screen -S monitoring -X screen -t "DB" 2 ssh db1 'tail -f /var/log/postgresql/postgresql.log'
screen -S monitoring -X screen -t "Cache" 3 ssh cache1 'redis-cli monitor'

# Attach zu Monitoring Dashboard
screen -r monitoring

Beispiel 10: Automated Screen Startup

Eine automatisierte screenrc-Datei erstellt beim Start mehrere Windows mit vordefinierten Programmen. Das ist wie ein Layout-System fuer screen: Du definierst einmal, welche Windows mit welchen Programmen geoeffnet werden sollen, und beim Start ist alles sofort bereit. In diesem Beispiel oeffnet Window 0 htop fuer System-Monitoring, Window 1 zeigt Live-Logs, Window 2 startet eine Bash fuer Git-Operationen und Window 3 ist ein leeres Terminal. Der select 2-Befehl am Ende setzt den Fokus auf das Git-Window, da das typischerweise das erste Window ist, in dem du arbeitest. Verwende diese Config-Datei mit screen -c ~/.screenrc.auto -S auto fuer einen spezialisierten Start.

# ~/.screenrc.auto
# Automatisches Setup beim Start

# Window 0: System Monitor
screen -t "System" 0 htop

# Window 1: Logs
screen -t "Logs" 1 tail -f /var/log/syslog

# Window 2: Git
screen -t "Git" 2 bash

# Window 3: Server
screen -t "Server" 3

# Starte bei Window 2
select 2

# Verwenden:
screen -c ~/.screenrc.auto -S auto

Beispiel 11: Emergency Recovery

Eine der wichtigsten Faehigkeiten mit screen ist das Wiederherstellen einer Session nach einem unerwarteten Verbindungsabbruch. Wenn deine SSH-Verbindung waehrend einer kritischen Operation abbricht, zeigt screen -ls die Session moeglicherweise noch als "Attached" an, obwohl kein Terminal mehr verbunden ist. Mit screen -d -r erzwingst du das Detach der alten Verbindung und attachst dich sofort neu. Alternativ kannst du mit screen -x ein Multi-Display-Attach durchfuehren, das auch ohne vorheriges Detach funktioniert. Im Terminal siehst du nach dem Recovery genau den Zustand, in dem du aufgehoert hast -- laufende Prozesse, Ausgaben, alles ist noch da. Diese Technik hat schon unzaehlige Deployments und Migrationen gerettet.

# SSH-Verbindung bricht ab während wichtiger Operation

# Erneut verbinden:
ssh user@server

# Laufende Screen-Sessions prüfen:
screen -ls
# Output: There is a screen on: 12345.pts-0.hostname (Attached)

# Force-attach (auch wenn Status "Attached"):
screen -d -r 12345

# Oder: Multi-Display attach
screen -x 12345

# Operation ist noch da und läuft!

Beispiel 12: Screen in Scripts

Screen laesst sich hervorragend in Automatisierungs-Scripts einbinden. Mit dem stuff-Befehl sendest du Tasteneingaben an eine laufende screen-Session, ohne selbst attached zu sein. In diesem Deployment-Script wird eine neue Session erstellt, dann werden nacheinander die Deployment-Schritte als Befehle "eingetippt". Das \n am Ende jedes Strings simuliert einen Enter-Tastendruck. Das ist besonders nuetzlich fuer automatisierte Deployments, bei denen du den Fortschritt jederzeit mit screen -r einsehen kannst. Stell dir vor, du triggerst das Deployment per Webhook: Das Script laeuft, die screen-Session zeigt den Live-Fortschritt, und du kannst dich bei Bedarf verbinden. Alte Sessions werden vorher aufgeraeumt, um Konflikte zu vermeiden.

#!/bin/bash
# Automatisiertes Deployment mit screen

PROJECT="myapp"
SESSION="${PROJECT}-deploy"

# Alte Session cleanup
screen -S "$SESSION" -X quit 2>/dev/null

# Neue Session starten
screen -dmS "$SESSION"

# Commands in Session ausführen
screen -S "$SESSION" -X stuff "cd /var/www/$PROJECT\n"
screen -S "$SESSION" -X stuff "git pull origin main\n"
screen -S "$SESSION" -X stuff "npm install\n"
screen -S "$SESSION" -X stuff "npm run build\n"
screen -S "$SESSION" -X stuff "pm2 restart $PROJECT\n"

echo "Deployment läuft in screen session: $SESSION"
echo "Attach mit: screen -r $SESSION"

Integration mit Claude Code

Claude kann screen nutzen für:

Mit screen kann Claude Code in einer persistenten Remote-Session laufen, die SSH-Disconnects ueberlebt. Das ist besonders wertvoll bei langfristigen Aufgaben auf Remote-Servern, wo die Internetverbindung instabil sein kann. Du verbindest dich per SSH, startest eine screen-Session und kannst jederzeit detachen, ohne dass Claude Code seine Arbeit verliert. Der Befehl screen -dRR ist dabei besonders praktisch: Er erstellt die Session falls noetig oder verbindet sich automatisch mit einer bestehenden. So brauchst du dir nie Sorgen machen, ob die Session schon existiert.

# Claude startet remote session
ssh server
screen -dRR claude-work

# Session überlebt Disconnects
# Claude kann Tasks laufen lassen und später prüfen

Langlebige Prozesse wie Machine-Learning-Training oder grosse Datenverarbeitungen laufen zuverlaessig in screen-Sessions. Du startest den Prozess mit -dmS im Hintergrund, und er laeuft unabhaengig von deiner Terminal-Session weiter. Die Ausgabe wird in eine Log-Datei umgeleitet, die du jederzeit lesen kannst. Mit screen -r kannst du dich an die Session anhaengen und den Live-Output sehen. Das ist robuster als nohup, weil du die Moeglichkeit behältst, interaktiv mit dem Prozess zu kommunizieren.

# Claude startet langläufige Operation
screen -dmS training bash -c "python train_model.py > output.log 2>&1"

# Claude kann später Status prüfen:
screen -r training
# Oder Log lesen:
tail -f screenlog.0

Mit screen kannst du mehrere SSH-Verbindungen zu verschiedenen Servern in einer einzigen Session verwalten. Jeder Server bekommt ein eigenes Window, und du wechselst mit Ctrl+a gefolgt von der Window-Nummer zwischen ihnen. Das ist besonders nuetzlich fuer System-Administratoren, die mehrere Server gleichzeitig ueberwachen oder konfigurieren muessen. Stell dir vor, du rollst ein Update auf Web-Server, Datenbank und Cache-Server gleichzeitig aus -- du kannst den Fortschritt auf allen Servern parallel beobachten.

# Claude managed mehrere Server gleichzeitig
screen -S servers
Ctrl+a c  # Window für jeden Server
ssh web1
Ctrl+a c
ssh db1
Ctrl+a c
ssh cache1

# Claude navigiert zwischen Servern mit Ctrl+a 0,1,2...

Dieses Python-Script zeigt, wie du screen programmatisch nutzen kannst, um Hintergrund-Tasks zu starten und deren Status zu pruefen. Der subprocess-Aufruf erstellt eine screen-Session mit einem Monitoring-Script, und spaeter pruefst du mit screen -ls, ob die Session noch laeuft. Das ist besonders nuetzlich in Automatisierungs-Workflows, wo du Tasks starten und deren Fortschritt ueberwachen musst. Claude Code kann dieses Pattern verwenden, um langlebige Analysen im Hintergrund laufen zu lassen.

# Claude-Script für background monitoring
import subprocess

# Task in screen starten
subprocess.run(['screen', '-dmS', 'monitor', 'python', 'monitor.py'])

# Status prüfen
result = subprocess.run(['screen', '-ls'], capture_output=True, text=True)
if 'monitor' in result.stdout:
    print("Monitor läuft in screen session")

Automatisierte Deployments in screen-Sessions kombinieren das Beste aus beiden Welten: Die Befehle werden automatisch ausgefuehrt, aber du kannst dich jederzeit an die Session anhaengen und den Fortschritt live verfolgen. Mit hardcopy kopierst du den aktuellen Bildschirminhalt der Session in eine Datei, ohne dich anhaengen zu muessen. Das ist perfekt fuer CI/CD-Pipelines, wo du den Deployment-Status programmatisch abfragen willst. Stell dir vor, das Deployment laeuft automatisch bei jedem Push, und du kannst den Status jederzeit pruefen.

# Claude führt deployment aus
screen -dmS deploy bash -c "
    git pull &&
    npm install &&
    npm run build &&
    pm2 restart all &&
    echo 'Deployment complete'
"

# Claude wartet und prüft Ergebnis
sleep 60
screen -S deploy -X hardcopy /tmp/deploy-output.txt
cat /tmp/deploy-output.txt

Workflow-Beispiel: Claude Remote Debugging

Remote Debugging erfordert verschiedene Perspektiven gleichzeitig: Anwendungs-Logs, Systemressourcen, Netzwerkverbindungen und einen interaktiven Debugger. In dieser screen-Session erstellst du fuer jede Perspektive ein Window und navigierst mit Ctrl+a und der Nummer zwischen ihnen. So kannst du schnell pruefen, ob der Fehler in den Logs sichtbar ist, ob Systemressourcen knapp werden oder ob Netzwerkprobleme die Ursache sind. Die Session ist persistent, sodass du die Debug-Ergebnisse auch spaeter noch analysieren kannst. Aktiviere Logging mit Ctrl+a H, um alle Erkenntnisse automatisch zu protokollieren.

# 1. Claude startet Debug-Session
screen -S debug

# 2. Windows für verschiedene Debug-Aspekte
# Window 0: Application Logs
tail -f /var/log/app/error.log

# Window 1: System Resources
htop

# Window 2: Network Connections
watch -n 2 'netstat -tuln'

# Window 3: Interactive Debugging
python -m pdb app.py

# 3. Claude navigiert zwischen Windows
# Ctrl+a 0,1,2,3 für verschiedene Perspektiven

# 4. Session persistent für spätere Analyse
Ctrl+a d

Claude Code Integration

Workflow 1: Claude Code auf Remote-Servern persistent nutzen

Auf Remote-Servern ist screen oft die einzige verfuegbare Multiplexer-Option, da es auf fast allen Unix-Systemen vorinstalliert ist. Du verbindest dich per SSH, startest eine screen-Session und laesst Claude Code darin laufen. Selbst wenn die SSH-Verbindung abbricht, arbeitet Claude Code weiter. Beim erneuten Verbinden siehst du den gesamten bisherigen Output und kannst die Ergebnisse analysieren. Das ist besonders wertvoll bei Server-Diagnosen, wo Claude Code Log-Dateien analysieren und Fehlerquellen identifizieren soll.

# SSH in Server, screen-Session fuer Claude Code starten
ssh user@remote-server
screen -S claude-work
claude "Analysiere die Logs in /var/log/app/ und finde Fehler"
# Ctrl+a d zum Detachen -- Claude Code arbeitet weiter

Workflow 2: Langlaeuige Claude Code Aufgaben im Hintergrund

Langlaeuige Aufgaben wie das Ausfuehren aller Tests und Erstellen eines Reports koennen in einer screen-Session im Daemon-Modus laufen. Der Befehl startet die Session im Hintergrund, Claude Code arbeitet darin, und die Ausgabe wird in eine Datei umgeleitet. Du kannst dich jederzeit mit screen -r an die Session anhaengen, um den Live-Fortschritt zu sehen, oder einfach spaeter die Report-Datei lesen. Das ist robuster als ein einfaches Hintergrund-Kommando mit &, weil du die interaktive Sitzung beibehaltst.

# Build + Test-Pipeline in screen starten
screen -dmS claude-pipeline bash -c "claude 'Fuehre alle Tests aus und erstelle einen Report' > /tmp/claude-report.txt 2>&1"
# Spaeter Ergebnis pruefen
screen -r claude-pipeline
cat /tmp/claude-report.txt

Workflow 3: Multi-Window Claude Code Debugging

Fuer ein effektives Debugging-Setup erstellst du drei separate Windows in einer screen-Session: eines fuer Claude Code selbst, eines fuer das Monitoring der Anwendungs-Logs und eines fuer die Systemressourcen-Ueberwachung mit htop. Du wechselst zwischen den Windows mit Ctrl+a gefolgt von der Window-Nummer. Claude Code kann im ersten Window Aenderungen vornehmen, waehrend du im Log-Window siehst ob Fehler auftreten und im htop-Window pruefst ob die CPU-Last normal bleibt. Das gibt dir einen umfassenden Ueberblick ueber die Auswirkungen jeder Aenderung.

# Screen-Session mit mehreren Windows fuer Debugging
screen -S debug
# Window 0: Claude Code
claude
# Ctrl+a c (neues Window)
# Window 1: Log-Monitoring
tail -f /var/log/app/error.log
# Ctrl+a c
# Window 2: System-Ressourcen
htop
💡 Tipp: Claude Code kann screen automatisch in Remote-Umgebungen einsetzen, wo tmux oder zellij nicht verfuegbar sind -- screen ist der universelle Fallback.

Video-Tutorial

Video: [Linux Screen Command Tutorial]() Praxisorientierte Einfuehrung in GNU screen mit Sessions, Windows, Splits und den wichtigsten Tastenkombinationen.

Troubleshooting

Hier findest du Loesungen fuer die haeufigsten screen-Probleme. Viele Fehler haengen mit Permissions oder Session-Status zusammen.

Problem: "Cannot open your terminal '/dev/pts/X'"

Dieser Fehler tritt auf, wenn die Berechtigungen auf das Terminal-Device nicht stimmen -- haeufig nach su oder sudo -u. Die Loesung ist, ein neues PTY via script zu erstellen:

# Ursache: Permissions auf TTY
# Lösung:
script /dev/null
# Dann screen starten

# Oder:
chmod 666 $(tty)
screen

Problem: Screen Session "Attached" aber nicht erreichbar

Die Session zeigt den Status "Attached", aber das Terminal, von dem sie gestartet wurde, ist nicht mehr verfuegbar (z.B. nach SSH-Abbruch). Mit Force-Detach kannst du sie zurueckholen:

# Force-Detach der Session
screen -d SESSION_ID

# Dann normal attach
screen -r SESSION_ID

# Oder: Multi-Display attach
screen -x SESSION_ID

Problem: Screen läuft aber screen -ls zeigt nichts

Dieses Problem tritt auf, wenn die Socket-Dateien beschaedigt sind oder die Berechtigungen auf das Socket-Verzeichnis nicht stimmen:

# Socket-Directory prüfen
ls -la /var/run/screen/

# Oder:
ls -la ~/.screen/

# Mit explizitem Socket-Pfad
screen -ls -S /var/run/screen/S-username/

# Socket-Permissions fixen
chmod 700 /var/run/screen/S-$USER

Problem: "Weird screen size" Warning

Diese Warnung tritt auf, wenn du eine screen-Session von einem Terminal mit anderer Groesse wieder oeffnest als dem, in dem sie gestartet wurde. Zum Beispiel hast du die Session auf einem 1080p-Monitor gestartet und oeffnest sie jetzt auf einem Laptop mit kleinerem Bildschirm. Screen passt die Groesse nicht automatisch an, sondern zeigt die Warnung an. Mit Ctrl+a F (Fit) zwingst du screen, sich an die aktuelle Terminal-Groesse anzupassen. In der screenrc kannst du mit der termcapinfo-Zeile dafuer sorgen, dass die Groessenanpassung automatisch erfolgt.

# Ursache: Terminal-Größe geändert zwischen Sessions
# Lösung: Screen über aktuelle Größe informieren
# In screen:
Ctrl+a F     # Fit to current window size

# Oder in .screenrc:
termcapinfo xterm* 'is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l'

Problem: Scrolling funktioniert nicht

In screen scrollt die Maus standardmaessig nicht wie gewohnt. Um den Scrollback-Buffer zu sehen, musst du den Copy Mode aktivieren:

# Copy-Mode aktivieren für Scrolling
Ctrl+a [
# Dann mit Pfeiltasten oder vi-keys scrollen
# ESC zum Verlassen

# Oder in .screenrc Mouse Scrolling aktivieren:
termcapinfo xterm* ti@:te@

Problem: Nested screen (screen in screen)

Wenn du aus Versehen screen innerhalb von screen startest, werden die Keybindings abgefangen. Pruefe vorher mit $STY, ob du bereits in screen bist:

# Check ob bereits in screen:
echo $STY
# Wenn output: Du bist in screen!

# Nested prefix verwenden: Ctrl+a a
# Dann normal weiter: Ctrl+a a c für neues Window im inneren screen

# Besser: Nested screen vermeiden
if [ -z "$STY" ]; then
    screen -dRR main
fi

Problem: screen session "Dead???"

"Dead"-Sessions entstehen, wenn der screen-Prozess abgestuerzt ist, aber die Socket-Datei noch existiert. Mit screen -wipe werden diese Leichen aufgeraeumt:

# Liste anzeigen:
screen -ls
# Output: 12345.sessionname (Dead ???)

# Dead Session entfernen:
screen -wipe

# Oder spezifisch:
screen -S 12345 -X quit

Problem: Colors nicht richtig dargestellt

Falsche Farben liegen oft an einer falschen TERM-Variable. Screen setzt standardmaessig screen als TERM, was nur 8 Farben unterstuetzt. Fuer 256 Farben muss die Einstellung angepasst werden:

# In .screenrc:
term screen-256color
defbce on  # Use current background color for erased chars

# Oder beim Start:
screen -T screen-256color

Vergleich mit Alternativen

| Feature | screen | tmux | zellij | byobu |
|---------|--------|------|--------|-------|
| Verfügbarkeit | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| Legacy-Support | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ |
| Memory Usage | ~3-5 MB | ~5-10 MB | ~15-30 MB | ~8-15 MB |
| Performance | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Intuitivität | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Split Panes | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Configuration | .screenrc | .tmux.conf | KDL/YAML | Config | Plugin System | ❌ | ⭐⭐ (TPM) | ⭐⭐⭐⭐ (WASM) | ⭐ |
| Session Persist | ✅ | ✅ | ✅ | ✅ |
| Copy Mode | Basic | Vim-like | Vim-like | Enhanced |
| Status Bar | Basic | Customizable | Modern | Enhanced |
| Serial Console | ✅ | ❌ | ❌ | ❌ |
| First Release | 1987 | 2007 | 2021 | 2008 |
| Community | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 🆕 Growing | ⭐⭐ |
| Documentation | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Learning Curve | Mittel | Mittel-Hoch | Niedrig | Niedrig-Mittel |

Wann screen wählen?

✅ Verwende screen wenn:

❌ Verwende tmux/zellij wenn:

Nützliche Links

Offizielle Ressourcen

Tutorials & Guides

Community

Pro-Tipps

Tipp 1: Schneller Session-Wechsel

Diese Shell-Funktion vereinfacht den Umgang mit screen-Sessions erheblich. Ohne Argument listet sie alle laufenden Sessions auf, mit Argument verbindet sie sich mit der angegebenen Session oder erstellt sie. Der -dRR-Parameter ist dabei der Schluessel: Er detacht eine eventuell haengende Session, erstellt sie bei Bedarf neu und verbindet sich. So brauchst du nur noch einen Befehl fuer alles -- kein separates screen -ls und screen -r mehr. Fuege die Funktion in deine Shell-Konfiguration ein, um sie dauerhaft verfuegbar zu machen.

# Function für ~/.bashrc
function ss() {
    if [ -z "$1" ]; then
        screen -ls
    else
        screen -dRR "$1"
    fi
}

# Verwendung:
ss              # Listet Sessions
ss work         # Attach/create "work" session

Tipp 2: Vertical Split via Patch

Standard-screen unterstuetzt nur horizontale Splits. Ab Version 4.2.0 ist aber auch der vertikale Split mit split -v verfuegbar. In der screenrc kannst du Keybindings definieren, die beide Split-Richtungen leicht zugaenglich machen. Mit bind v split -v legst du den vertikalen Split auf die Taste v (nach Ctrl+a), und mit bind s split den horizontalen auf s. Das macht das Split-System deutlich flexibler und naeher an das, was tmux und zellij bieten. Pruefe mit screen --version, ob deine Version vertikale Splits unterstuetzt.

# Standard screen hat nur horizontal split
# Vertical split verfügbar mit screen-4.2.0+

# In .screenrc:
bind v split -v
bind h split

# Oder vim-style:
bind s split
bind v split -v

Tipp 3: Screen als Clipboard

Screen hat einen internen Clipboard-Buffer, der ueber die Datei /tmp/screen-exchange funktioniert. Mit dem Copy Mode (Ctrl+a [) markierst du Text, der in diesen Buffer kopiert wird. Mit diesem Keybinding verbindest du den screen-Buffer mit der System-Zwischenablage, sodass kopierter Text auch ausserhalb von screen verfuegbar ist. Auf macOS nutzt du dafuer pbcopy, auf Linux xclip. Das ist besonders nuetzlich, wenn du Logzeilen oder Fehlermeldungen aus einer screen-Session in andere Anwendungen uebernehmen willst. Definiere den Binding in deiner screenrc, damit er bei jedem Start verfuegbar ist.

# Text in screen kopieren (Ctrl+a [)
# Dann in anderem System via screen abrufen

# In .screenrc:
bind b eval "writebuf" "exec sh -c 'pbcopy < /tmp/screen-exchange'"  # macOS
bind b eval "writebuf" "exec sh -c 'xclip -i < /tmp/screen-exchange'"  # Linux

Tipp 4: Status-Line mit mehr Info

Eine erweiterte Status-Line zeigt dir wichtige Informationen auf einen Blick: die Window-Liste mit dem aktiven Window hervorgehoben, den Hostnamen, Datum und Uhrzeit. Das ist besonders hilfreich, wenn du viele Windows offen hast und schnell sehen willst, in welchem du dich befindest. Die caption always-Direktive sorgt dafuer, dass die Status-Line immer sichtbar ist. Die Formatierung verwendet spezielle screen-Escape-Sequenzen fuer Farben und Inhalte. Experimentiere mit den Parametern, um deine ideale Ansicht zu finden -- die screen-Manpage dokumentiert alle verfuegbaren Format-Strings.

# In .screenrc erweiterte Status-Line
caption always "%{= kw}%-w%{= BW}%n %t%{-}%+w %-= @%H - %LD %d %LM - %c"

# Zeigt:
# - Window-Liste mit aktuellem Window highlighted
# - Hostname
# - Datum und Uhrzeit

Tipp 5: Automatisches Logging

Automatisches Logging zeichnet jeden Output in allen Windows auf. Das ist unverzichtbar bei kritischen Operationen wie Deployments oder Datenbank-Migrationen, deren Output du spaeter analysieren musst. Der Dateiname enthaelt den Window-Titel und das Datum, sodass du die Logs leicht zuordnen kannst. Alte Logs werden mit dem find-Befehl nach 30 Tagen automatisch geloescht, um Speicherplatz zu sparen. Erstelle das Log-Verzeichnis einmalig und fuege die Einstellungen in deine screenrc ein.

# In .screenrc
deflog on
logfile $HOME/logs/screen-%t-%Y%m%d.log

# Erstelle log-Directory:
mkdir -p ~/logs

# Logs automatisch rotieren:
find ~/logs -name "screen-*.log" -mtime +30 -delete

Tipp 6: Screen + SSH Agent Forwarding

SSH Agent Forwarding ist ein haeufiges Problem in screen-Sessions: Wenn du dich per SSH mit Agent-Forwarding verbindest, eine screen-Session startest und spaeter die SSH-Verbindung trennst, verliert die screen-Session den Zugriff auf den SSH-Agent. Der Grund ist, dass der Socket-Pfad sich bei jeder SSH-Verbindung aendert. Die Loesung ist ein symbolischer Link an einem festen Ort, der bei jeder SSH-Verbindung aktualisiert wird. Fuege den Code in deine bashrc ein, und der SSH-Agent funktioniert auch in screen-Sessions nach einem Reconnect. Ohne diesen Fix wuerden git push und ssh-Befehle in der screen-Session nach einem Reconnect fehlschlagen.

# SSH Agent in screen verfügbar machen
# In .screenrc:
setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK

# Oder in .bashrc vor screen start:
if [ -n "$SSH_AUTH_SOCK" ]; then
    ln -sf "$SSH_AUTH_SOCK" ~/.ssh/ssh_auth_sock
    export SSH_AUTH_SOCK=~/.ssh/ssh_auth_sock
fi

Tipp 7: Screen Exit bei letztem Window

Standardmaessig bleibt screen offen, auch wenn das letzte Window geschlossen wird. Mit diesen Einstellungen kannst du das Verhalten anpassen. Die zombie kr-Option ist besonders interessant: Wenn ein Programm in einem Window beendet wird, zeigt screen statt des leeren Windows einen Hinweis an und bietet dir die Wahl, das Window zu killen (k) oder das Programm neu zu starten (r). Das verhindert, dass versehentlich geschlossene Windows verloren gehen. Passe die Keybindings an deine Vorlieben an.

# In .screenrc
# Automatisch screen beenden wenn letztes Window schließt
bind k kill
bind ^k kill

# Oder: Zombie Windows vermeiden
zombie kr  # k=kill r=respawn

Tipp 8: Screen fuer Background Scripts

Dieses Wrapper-Script startet beliebige Befehle in einer benannten screen-Session im Hintergrund. Es nimmt den Task-Namen als erstes Argument und den auszufuehrenden Befehl als Rest. Nach Beendigung des Befehls wartet das Script auf einen Tastendruck, damit du das Ergebnis noch lesen kannst, bevor das Window schliesst. Das ist nuetzlich fuer automatisierte Build-Prozesse, Datenverarbeitungen oder jede andere Aufgabe, die du im Hintergrund ausfuehren willst. Du bekommst eine Bestaetigung mit dem Attach-Befehl, um den Fortschritt jederzeit pruefen zu koennen.

#!/bin/bash
# Wrapper-Script für background tasks

TASK_NAME="$1"
shift  # Rest sind die auszuführenden Commands

screen -dmS "$TASK_NAME" bash -c "$@; echo 'Task finished. Press any key to close.'; read"

echo "Task '$TASK_NAME' gestartet in screen."
echo "Attach mit: screen -r $TASK_NAME"

Tipp 9: Screen Hardcopy (Screenshot)

Mit Hardcopy speicherst du den aktuellen Bildschirminhalt einer screen-Session als Text-Datei. Das ist nuetzlich fuer Dokumentation, Fehlerberichte oder wenn du den aktuellen Zustand einer Session festhalten willst, ohne einen Screenshot zu machen. Besonders praktisch ist der programmatische Zugriff von aussen mit screen -X hardcopy, mit dem du den Inhalt einer laufenden Session in eine Datei exportieren kannst, ohne dich anhaengen zu muessen. Das eignet sich hervorragend fuer Monitoring-Scripts, die regelmaessig den Zustand einer Session pruefen.

# Screen-Inhalt in Datei speichern
Ctrl+a h    # Hardcopy in ~/hardcopy.X

# Oder gezielt:
# In .screenrc:
bind h hardcopy -h $HOME/screen-hardcopy.txt

# Programmatisch von außen:
screen -S sessionname -X hardcopy /tmp/screen-capture.txt

Tipp 10: Screen Monitoring Mode

Der Monitoring Mode ueberwacht ein Background-Window und benachrichtigt dich, wenn dort neue Ausgabe erscheint. Das ist perfekt fuer Situationen, wo du auf einen langen Prozess wartest: Du schaltest Monitoring fuer das Window mit dem Build ein und arbeitest in einem anderen Window. Sobald der Build Output generiert (z.B. fertig ist oder einen Fehler wirft), zeigt screen eine Benachrichtigung. Mit defmonitor on in der screenrc aktivierst du das Feature standardmaessig fuer alle Windows. Die activity-Meldung kann angepasst werden, um den Window-Namen und die Nummer anzuzeigen.

# Window-Aktivität überwachen
Ctrl+a M    # Monitoring toggle
# Screen warnt wenn Output im Background-Window

# Oder in .screenrc:
defmonitor on
activity "Activity in window %n (%t)"

Zusammenfassung

GNU screen ist der klassische, bewährte Terminal-Multiplexer mit über 35 Jahren Produktionseinsatz. Trotz weniger moderner Features als tmux oder zellij bleibt screen relevant durch universelle Verfügbarkeit, minimalen Footprint und Zuverlässigkeit.

Hauptvorteile:

Hauptnachteile:

Ideal für:

Alternativen:

Nächste Schritte:

screen bleibt ein wichtiges Tool im Arsenal jedes System-Administrators – besonders wenn Zuverlässigkeit und Kompatibilität wichtiger sind als moderne Features! 🖥️