about_Redirection

Kurzbeschreibung

Erklärt, wie die Ausgabe von PowerShell in Textdateien umgeleitet wird.

Lange Beschreibung

Standardmäßig sendet PowerShell die Ausgabe an den PowerShell-Host. In der Regel ist dies die Konsolenanwendung. Sie können die Ausgabe jedoch an eine Textdatei umleiten, und Sie können die Fehlerausgabe an den regulären Ausgabedatenstrom umleiten.

Sie können die folgenden Methoden verwenden, um die Ausgabe umzuleiten:

  • Verwenden Sie das Cmdlet Out-File, das die Befehlsausgabe an eine Textdatei sendet. In der Regel verwenden Sie das cmdlet Out-File, wenn Sie dessen Parameter wie Encoding, Force, Widthoder NoClobber Parameter verwenden müssen.

  • Verwenden Sie das Cmdlet Tee-Object, das die Befehlsausgabe an eine Textdatei sendet und sie dann an die Pipeline sendet.

  • Verwenden Sie die PowerShell-Umleitungsoperatoren. Das Umleiten der Ausgabe eines PowerShell-Befehls (Cmdlet, Funktion, Skript) mithilfe des Umleitungsoperators (>) entspricht funktionell der Weiterleitung an Out-File ohne zusätzlicher Parameter. PowerShell 7.4 hat das Verhalten des Umleitungsoperators geändert, wenn der stdout Stream eines systemeigenen Befehls umgeleitet wird.

Weitere Informationen zu Datenströmen finden Sie unter about_Output_Streams.

Umleitungsfähige Ausgabedatenströme

PowerShell unterstützt die Umleitung der folgenden Ausgabedatenströme.

Bach # Beschreibung Eingeführt in Cmdlet schreiben
1 Erfolgsstream PowerShell 2.0 Write-Output
2 Fehlerstream PowerShell 2.0 Write-Error
3 Warnungsstream PowerShell 3.0 Write-Warning
4 Ausführlicher Stream PowerShell 3.0 Write-Verbose
5 Debugstream PowerShell 3.0 Write-Debug
6 Informationsstream PowerShell 5.0 Write-Information, Write-Host
* Alle Datenströme PowerShell 3.0

Es gibt auch einen Progress Stream in PowerShell, unterstützt jedoch keine Umleitung.

Wichtig

Die Success und Error streams ähneln den STDOUT- und STDERR-Streams anderer Shells. Stdin ist jedoch nicht mit der PowerShell-Pipeline für eingaben verbunden.

PowerShell-Umleitungsoperatoren

Die Umleitungsoperatoren von PowerShell sind wie folgt, wobei n die Nummer des Datenstroms darstellt. Der Success Stream ( 1 ) ist die Standardeinstellung, wenn kein Datenstrom angegeben ist.

Operator Beschreibung Syntax
> Senden des angegebenen Datenstroms an eine Datei. n>
>> Anhängen des angegebenen Datenstroms an eine Datei. n>>
>&1 leitet den angegebenen Datenstrom zum Success Stream um. n>&1

Anmerkung

Im Gegensatz zu einigen Unix-Shells können Sie nur andere Streams an den Success Stream umleiten.

Umleiten der Ausgabe von systemeigenen Befehlen

PowerShell 7.4 hat das Verhalten der Umleitungsoperatoren geändert, wenn sie verwendet werden, um den stdout Datenstrom eines systemeigenen Befehls umzuleiten. Die Umleitungsoperatoren behalten nun die Daten des Byte-Datenstroms bei, wenn die Ausgabe aus einem nativen Befehl umgeleitet wird. PowerShell interpretiert die umgeleiteten Daten nicht oder fügt keine zusätzliche Formatierung hinzu. Weitere Informationen finden Sie unter Beispiel Nr. 7.

Examples

Beispiel 1: Umleiten von Fehlern und Ausgaben in eine Datei

In diesem Beispiel wird dir für ein Element ausgeführt, das erfolgreich ist, und eines, das fehlschlägt.

dir C:\, fakepath 2>&1 > .\dir.log

Es verwendet 2>&1, um den Error Strom an den Success Strom umzuleiten, und >, um den resultierenden Success Strom an eine Datei mit dem Namen dir.log zu senden.

Beispiel 2: Senden aller Erfolgsstreamdaten an eine Datei

In diesem Beispiel werden alle Success Streamdaten an eine Datei mit dem Namen script.loggesendet.

.\script.ps1 > script.log

Beispiel 3: Senden von Erfolgs-, Warnungs- und Fehlerdatenströmen an eine Datei

In diesem Beispiel wird gezeigt, wie Sie Umleitungsoperatoren kombinieren können, um ein gewünschtes Ergebnis zu erzielen.

&{
   Write-Warning "hello"
   Write-Error "hello"
   Write-Output "hi"
} 3>&1 2>&1 > C:\Temp\redirection.log
  • 3>&1 leitet den Warning Stream an den Success Stream um.
  • 2>&1 leitet den Fehlerstream an den Erfolgsstream um (der nun auch alle Daten des Warnungsstreams enthält)
  • > leitet den Success Stream (der jetzt sowohl Warnungs- als auch Fehler datenströme enthält) an eine Datei mit dem Namen C:\temp\redirection.logum.

Beispiel 4: Umleiten aller Datenströme zu einer Datei

In diesem Beispiel werden alle Datenströme aus einem Skript mit dem Namen script.ps1 an eine Datei mit dem Namen script.loggesendet.

.\script.ps1 *> script.log

Beispiel 5: Unterdrücken aller Write-Host- und Informationsstreamdaten

In diesem Beispiel werden alle Informationen im Datenstrom unterdrückt. Weitere Informationen zu Informationsstream-Cmdlets finden Sie unter Write-Host- und Write-Information

&{
   Write-Host "Hello"
   Write-Information "Hello" -InformationAction Continue
} 6> $null

Beispiel 6: Anzeigen der Auswirkung von Aktionseinstellungen

Aktionseinstellungsvariablen und -parameter können ändern, was in einen bestimmten Datenstrom geschrieben wird. Das Skript in diesem Beispiel zeigt, wie sich der Wert von $ErrorActionPreference darauf auswirkt, was in den Error Stream geschrieben wird.

$ErrorActionPreference = 'Continue'
$ErrorActionPreference > log.txt
Get-Item /not-here 2>&1 >> log.txt

$ErrorActionPreference = 'SilentlyContinue'
$ErrorActionPreference >> log.txt
Get-Item /not-here 2>&1 >> log.txt

$ErrorActionPreference = 'Stop'
$ErrorActionPreference >> log.txt
try {
    Get-Item /not-here 2>&1 >> log.txt
}
catch {
    "`tError caught!" >> log.txt
}
$ErrorActionPreference = 'Ignore'
$ErrorActionPreference >> log.txt
Get-Item /not-here 2>&1 >> log.txt

$ErrorActionPreference = 'Inquire'
$ErrorActionPreference >> log.txt
Get-Item /not-here 2>&1 >> log.txt

$ErrorActionPreference = 'Continue'

Wenn wir dieses Skript ausführen, erhalten wir eine Aufforderung, wenn $ErrorActionPreference auf Inquire festgelegt ist.

PS C:\temp> .\test.ps1

Confirm
Can't find path 'C:\not-here' because it doesn't exist.
[Y] Yes  [A] Yes to All  [H] Halt Command  [S] Suspend  [?] Help (default is "Y"): H
Get-Item: C:\temp\test.ps1:23
Line |
  23 |  Get-Item /not-here 2>&1 >> log.txt
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | The running command stopped because the user selected the Stop option.

Wenn wir die Protokolldatei untersuchen, sehen wir Folgendes:

PS C:\temp> Get-Content .\log.txt
Continue

Get-Item: C:\temp\test.ps1:3
Line |
   3 |  Get-Item /not-here 2>&1 >> log.txt
     |  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'C:\not-here' because it does not exist.

SilentlyContinue
Stop
    Error caught!
Ignore
Inquire

Beispiel 7: Umleiten von Binärdaten aus einem nativen Befehl

Ab PowerShell 7.4 behält PowerShell die Byte-Stream-Daten bei, wenn der stdout Datenstrom eines nativen Kommandos in eine Datei umgeleitet wird oder wenn Byte-Stream-Daten an den stdin Datenstrom eines nativen Kommandos weitergeleitet werden.

Beispielsweise können Sie mithilfe des systemeigenen Befehls curl eine Binärdatei herunterladen und mithilfe der Umleitung auf dem Datenträger speichern.

$uri = 'https://github.com/PowerShell/PowerShell/releases/download/v7.3.7/powershell-7.3.7-linux-arm64.tar.gz'

# native command redirected to a file
curl -s -L $uri > powershell.tar.gz

Sie können die Bytestreamdaten auch an den stdin- Stream eines anderen nativen Befehls weiterverleitungen. Im folgenden Beispiel wird eine zippierte TAR-Datei mit curlheruntergeladen. Die heruntergeladenen Dateidaten werden an den befehl tar gestreamt, um den Inhalt des Archivs zu extrahieren.

# native command output piped to a native command
curl -s -L $uri | tar -xzvf - -C .

Sie können auch die Bytestreamausgabe eines PowerShell-Befehls an die Eingabe eines nativen Befehls weiterleiten. In den folgenden Beispielen werden Invoke-WebRequest zum Herunterladen derselben TAR-Datei wie im vorherigen Beispiel verwendet.

# byte stream piped to a native command
(Invoke-WebRequest $uri).Content | tar -xzvf - -C .

# bytes piped to a native command (all at once as byte[])
,(Invoke-WebRequest $uri).Content | tar -xzvf - -C .

Dieses Feature unterstützt keine Bytestreamdaten beim Umleiten der stderr-Ausgabe an stdout. Wenn Sie die stderr- und stdout- Datenströme kombinieren, werden die kombinierten Datenströme als Zeichenfolgendaten behandelt.

Hinweise

Die Umleitungsoperatoren, die keine Daten anfügen (> und n>) überschreiben den aktuellen Inhalt der angegebenen Datei ohne Warnung.

Wenn es sich bei der Datei jedoch um eine schreibgeschützte, ausgeblendete oder Systemdatei handelt, schlägt die Umleitung fehl. Die Anfügeumleitungsoperatoren (>> und n>>) schreiben nicht in eine nur lesbare Datei, fügen jedoch Inhalte an eine System- oder versteckte Datei an.

Um die Umleitung von Inhalten auf eine schreibgeschützte, ausgeblendete oder Systemdatei zu erzwingen, verwenden Sie das cmdlet Out-File mit dem Force-Parameter.

Wenn Sie in Dateien schreiben, verwenden die Umleitungsoperatoren die UTF8NoBOM-Kodierung. Wenn die Datei eine andere Codierung aufweist, ist die Ausgabe möglicherweise nicht ordnungsgemäß formatiert. Um in Dateien mit einer anderen Codierung zu schreiben, verwenden Sie das cmdlet Out-File mit seinem Encoding-Parameter.

Breite der Ausgabe beim Schreiben in eine Datei

Wenn Sie in eine Datei schreiben, indem Sie entweder Out-File oder die Umleitungsoperatoren verwenden, formatiert PowerShell die Tabellenausgabe basierend auf der Breite der Konsole, in der sie ausgeführt wird. Wenn z. B. die Ausgabe der Tabelle mit einem Befehl wie Get-ChildItem Env:\Path > path.log auf einem System protokolliert wird, in dem die Konsolenbreite auf 80 Spalten festgelegt ist, wird die Ausgabe in der Datei auf 80 Zeichen abgeschnitten:

Name                         Value
----                         -----
Path                         C:\Program Files\PowerShell\7;C:\WINDOWS…

In Anbetracht der Tatsache, dass die Konsolenbreite auf Systemen, auf denen Ihr Skript ausgeführt wird, beliebig festgelegt werden kann, sollten Sie die Ausgabe der PowerShell-Formattabelle auf Dateien basierend auf einer von Ihnen angegebenen Breite bevorzugen.

Das cmdlet Out-File stellt einen Width Parameter bereit, mit dem Sie die gewünschte Breite für die Tabellenausgabe festlegen können. Anstatt -Width 2000 überall hinzufügen zu müssen, wo Sie Out-Fileaufrufen, können Sie die $PSDefaultParameterValues Variable verwenden, um diesen Wert für alle Verwendungen des cmdlets Out-File in einem Skript festzulegen. Da die Umleitungsoperatoren (> und >>) effektiv Aliase für Out-Filesind, wirkt sich das Festlegen des Out-File:Width Parameters für das gesamte Skript auch auf die Formatierungsbreite für die Umleitungsoperatoren aus. Platzieren Sie den folgenden Befehl am oberen Rand des Skripts, um Out-File:Width für das gesamte Skript festzulegen:

$PSDefaultParameterValues['Out-File:Width'] = 2000

Wenn Sie die Ausgabebreite erhöhen, erhöht sich der Arbeitsspeicherverbrauch beim Protokollieren der formatierten Tabellenausgabe. Wenn Sie viele Tabellendaten in eine Datei protokollieren und wissen, dass Sie mit einer kleineren Breite arbeiten können, verwenden Sie die kleinere Breite.

In einigen Fällen, wie bei der Get-Service-Ausgabe, müssen Sie, um die zusätzliche Breite zu nutzen, die Ausgabe vor der Speicherung in eine Datei durch Format-Table -AutoSize leiten.

$PSDefaultParameterValues['Out-File:Width'] = 2000
Get-Service | Format-Table -AutoSize > services.log

Weitere Informationen zu $PSDefaultParameterValues finden Sie unter about_Preference_Variables.

Potenzielle Verwirrung mit Vergleichsoperatoren

Der >-Operator ist nicht mit dem Größer-als- Vergleichsoperator zu verwechseln (häufig als > in anderen Programmiersprachen bezeichnet).

Je nach verglichenen Objekten kann die Ausgabe mit > korrekt erscheinen (da 36 nicht größer als 42 ist).

PS> if (36 > 42) { "true" } else { "false" }
false

Eine Überprüfung des lokalen Dateisystems kann jedoch sehen, dass eine Datei mit dem Namen 42 geschrieben wurde, mit dem Inhalt 36.

PS> dir

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
------          1/02/20  10:10 am              3 42

PS> cat 42
36

Beim Versuch, den umgekehrten Vergleich < (kleiner als) zu verwenden, tritt ein Systemfehler auf:

PS> if (36 < 42) { "true" } else { "false" }
ParserError:
Line |
   1 |  if (36 < 42) { "true" } else { "false" }
     |         ~
     | The '<' operator is reserved for future use.

Wenn ein numerischer Vergleich der erforderliche Vorgang ist, sollten -lt und -gt verwendet werden. Weitere Informationen zum -gt Operator finden Sie unter about_Comparison_Operators.

Siehe auch

  • Last updated on