Kurz gesagt: PowerShell Read-Host liest Nutzereingaben interaktiv von der Konsole ein, prüft sie aber nicht automatisch auf Gültigkeit. Du musst Eingabetyp, Leerwerte und Sonderzeichen selbst kontrollieren, Passwörter über AsSecureString maskieren und bei kritischen Skripten zusätzlich Parameter-Validierung mit ValidateSet oder ValidatePattern einsetzen, statt dich allein auf Read-Host zu verlassen.
Ein Kollege ruft dich an: Sein Onboarding-Skript mit PowerShell Read-Host hat den Servernamen falsch übernommen, weil niemand die Eingabe geprüft hat, und jetzt zeigt die halbe Abteilung auf den falschen Host. Genau solche Situationen entstehen, weil Read-Host zwar schnell eingebaut ist, aber ohne eigene Prüfung praktisch alles akzeptiert. Deshalb lohnt sich ein genauer Blick darauf, wie das Cmdlet arbeitet und wo du selbst nachbessern musst.
PowerShell Read-Host liest Eingaben direkt von der Konsole ein
Read-Host ist ein einfaches Cmdlet, das die Ausführung eines Skripts anhält und auf eine Texteingabe über die Tastatur wartet. Es gibt keine eingebaute Typprüfung, keine Längenbegrenzung und auch keine Pflichtfeld-Logik. Alles, was du bekommst, ist eine Zeichenkette, egal ob der Nutzer eine Zahl, einen Namen oder nur Leertaste plus Enter eingibt.
Genau deshalb ist PowerShell Read-Host für schnelle interaktive Skripte praktisch, für produktive Automatisierung aber riskant. Ein Skript, das Servernamen, IP-Adressen oder Nutzerkonten per Read-Host abfragt, sollte die Rückgabe immer selbst prüfen, bevor damit weitergearbeitet wird.
$server = Read-Host -Prompt 'Servername eingeben'
if ([string]::IsNullOrWhiteSpace($server)) {
Write-Warning 'Keine Eingabe erkannt, Skript wird beendet.'
exit
}
Dieser kurze Block fängt den häufigsten Fehler ab: eine leere Eingabe, die sonst unbemerkt weiterverarbeitet würde.
So validierst du Eingaben mit Read-Host zuverlässig
Eine saubere Validierung besteht meist aus einer Schleife, die so lange nach einer gültigen Eingabe fragt, bis das Format passt. Damit lässt sich PowerShell Read-Host auch für strukturierte Daten wie IP-Adressen oder E-Mail-Formate absichern.
do {
$ip = Read-Host -Prompt 'IP-Adresse eingeben'
} until ($ip -match '^\d{1,3}(\.\d{1,3}){3}$')
Write-Output "Gültige IP: $ip"
Der reguläre Ausdruck prüft nur das Format, nicht ob die Adresse tatsächlich existiert. Für kritische Skripte ergänzt du deshalb noch Test-Connection oder eine Bereichsprüfung.
Ein Standardwert erspart unnötige Rückfragen
Häufig gesucht wird die Frage nach einem PowerShell Read-Host Default-Wert. Read-Host selbst kennt keinen eingebauten Default-Parameter, du musst ihn über eine leere Eingabe abfangen.
$port = Read-Host -Prompt 'Port (Standard 443)'
if ([string]::IsNullOrWhiteSpace($port)) { $port = 443 }
So bekommt der Anwender eine sinnvolle Vorgabe, ohne dass das Skript bei leerer Eingabe abbricht.
Farbige Prompts verbessern die Lesbarkeit
Read-Host selbst hat keinen ForegroundColor-Parameter. Für farbige Hinweise nutzt du deshalb Write-Host direkt davor, etwa um Warnungen von normalen Abfragen optisch zu trennen.
Write-Host 'Achtung: Produktivsystem' -ForegroundColor Red
$confirm = Read-Host -Prompt 'Fortfahren? (j/n)'
Diese Kombination wird oft mit “PowerShell Read-Host ForegroundColor” gesucht, weil Admins die Farbe des Prompts selbst nicht ändern können, sondern nur den Text davor.
Passwörter gehören maskiert eingegeben
Bei der Abfrage von Zugangsdaten reicht ein normales Read-Host nicht aus, weil das Passwort im Klartext auf dem Bildschirm erscheint. Für PowerShell Read-Host Passwort-Eingaben nutzt du deshalb den Parameter AsSecureString.
$pw = Read-Host -Prompt 'Passwort' -AsSecureString
$cred = New-Object System.Management.Automation.PSCredential('benutzer', $pw)
Damit wird die Eingabe maskiert dargestellt und im Speicher als SecureString gehalten, was für den PowerShell Read-Host Mask-Input-Anwendungsfall die Standardlösung ist. Wie unsicherer Umgang mit Zugangsdaten in Microsoft-Umgebungen zu echten Vorfällen führt, zeigt der Artikel zu Secrets-Management in Microsoft-Umgebungen. Details zur SecureString-Konvertierung findest du zudem in der offiziellen Read-Host-Dokumentation von Microsoft.
Ja/Nein-Abfragen lassen sich einfach selbst bauen
Ein PowerShell Read-Host Yes-No-Dialog ist kein eingebautes Feature, sondern ein einfacher Vergleich der Eingabe. Am robustesten ist eine Schleife, die nur j, n, y oder Enter für den Default akzeptiert.
do {
$answer = (Read-Host -Prompt 'Fortfahren? (J/N)').ToLower()
} until ($answer -in 'j','n')
if ($answer -eq 'n') { exit }
So verhinderst du, dass eine versehentliche Eingabe wie “ja klar” fälschlich als Bestätigung durchgeht.
Mehrere Werte in einer Zeile einlesen funktioniert mit Split
Für PowerShell Read-Host Multiple-Values-Szenarien, etwa mehrere Servernamen kommagetrennt, hilft die Split-Methode direkt nach der Eingabe.
$input = Read-Host -Prompt 'Servernamen, kommagetrennt'
$servers = $input -split ',' | ForEach-Object { $_.Trim() }
Jeder Eintrag wird anschließend getrimmt, damit versehentliche Leerzeichen nach dem Komma keine falschen Hostnamen erzeugen.
Ein Timeout für Read-Host gibt es nicht von Haus aus
Viele Admins suchen nach einem PowerShell Read-Host Timeout, um Skripte bei fehlender Eingabe automatisch weiterlaufen zu lassen. Read-Host selbst unterstützt das nicht, deshalb weicht man meist auf einen Hintergrund-Job oder .NET-Konsolenzugriff aus.
$job = Start-Job { Read-Host -Prompt 'Eingabe (10 Sek. Zeit)' }
if (Wait-Job $job -Timeout 10) {
$result = Receive-Job $job
} else {
Remove-Job $job -Force
$result = 'Standardwert'
}
Diese Lösung ist ein Workaround und keine offizielle Funktion, funktioniert in der Praxis aber zuverlässig für unattended Fallbacks.
Sicherheit endet nicht bei der Eingabemaske
PowerShell Read-Host ersetzt keine echte Parametervalidierung. Für produktive Skripte, die mehrfach laufen, ist ein Parameterblock mit ValidateSet, ValidatePattern oder ValidateNotNullOrEmpty die robustere Wahl gegenüber einer reinen Konsolenabfrage.
Wer sich generell tiefer mit den Möglichkeiten der Shell beschäftigen will, findet einen guten Einstieg im Artikel über die wichtigsten PowerShell-Parameter. Wer Eingaben aus Read-Host anschließend in strukturierte Dateien schreibt, findet passende Grundlagen im Beitrag zu XML-Dateien mit PowerShell.
Häufige Fehler
- Leere Eingabe wird nicht abgefangen: Prüfe jede Rückgabe von Read-Host mit IsNullOrWhiteSpace, bevor du sie weiterverarbeitest.
- Passwörter werden im Klartext abgefragt: Nutze immer -AsSecureString statt eines normalen Read-Host-Aufrufs für Zugangsdaten.
- Groß- und Kleinschreibung bei Ja/Nein-Abfragen wird nicht berücksichtigt: Wandle die Eingabe vor dem Vergleich mit ToLower() um.
- Read-Host wird in automatisierten, nicht interaktiven Skripten eingesetzt: Solche Skripte bleiben ohne sichtbare Meldung hängen, deshalb gehört interaktive Eingabe nicht in geplante Tasks.
- Eingaben werden ungeprüft in Pfade oder Befehle eingebaut: Validiere Sonderzeichen, um versehentliche Command-Injection oder ungültige Pfade zu vermeiden.
