about_Redirection
Descripción breve
Explica cómo redirigir la salida de PowerShell a archivos de texto.
Descripción larga
De forma predeterminada, PowerShell envía la salida al host de PowerShell. Normalmente se trata de la aplicación de consola. Sin embargo, puede redirigir la salida a un archivo de texto y puede redirigir la salida de error al flujo de salida normal.
Puede usar los métodos siguientes para redirigir la salida:
Use el
Out-File
cmdlet , que envía la salida del comando a un archivo de texto. Normalmente, se usa elOut-File
cmdlet cuando necesite usar sus parámetros, como losEncoding
parámetros ,Force
,Width
oNoClobber
.Use el
Tee-Object
cmdlet , que envía la salida del comando a un archivo de texto y, a continuación, lo envía a la canalización.Use los operadores de redireccionamiento de PowerShell. Redirigir la salida de un comando de PowerShell (cmdlet, función, script) mediante el operador de redirección (
>
) es funcionalmente equivalente a canalizar aOut-File
sin parámetros adicionales. PowerShell 7.4 cambió el comportamiento del operador de redirección cuando se usa para redirigir la secuencia stdout de un comando nativo.
Para obtener más información sobre las secuencias, consulte about_Output_Secuencias.
Flujos de salida redirigibles
PowerShell admite el redireccionamiento de los siguientes flujos de salida.
Corriente # | Descripción | Introducida en | Write Cmdlet |
---|---|---|---|
1 | Secuencia correcta | PowerShell 2.0 | Write-Output |
2 | Secuencia de errores | PowerShell 2.0 | Write-Error |
3 | Secuencia de advertencia | PowerShell 3.0 | Write-Warning |
4 | Secuencia detallada | PowerShell 3.0 | Write-Verbose |
5 | Depuración de stream | PowerShell 3.0 | Write-Debug |
6 | Flujo de información | PowerShell 5.0 | Write-Information , Write-Host |
* | Todos los Secuencias | PowerShell 3.0 |
También hay un flujo de progreso en PowerShell, pero no admite el redireccionamiento.
Importante
Las secuencias success y Error son similares a las secuencias stdout y stderr de otros shells. Sin embargo, stdin no está conectado a la canalización de PowerShell para la entrada.
Operadores de redireccionamiento de PowerShell
Los operadores de redireccionamiento de PowerShell son los siguientes, donde n
representa el número de secuencia. La secuencia success ( 1
) es el valor predeterminado si no se especifica ninguna secuencia.
Operator | Description | Sintaxis |
---|---|---|
> |
Envíe una secuencia especificada a un archivo. | n> |
>> |
Anexe la secuencia especificada a un archivo. | n>> |
>&1 |
Redirige la secuencia especificada a la secuencia Correcta. | n>&1 |
Nota:
A diferencia de algunos shells de Unix, solo puede redirigir otras secuencias a la secuencia Success .
Redireccionamiento de la salida desde comandos nativos
PowerShell 7.4 cambió el comportamiento de los operadores de redirección cuando se usa para redirigir la secuencia stdout de un comando nativo. Los operadores de redireccionamiento ahora conservan los datos de secuencia de bytes al redirigir la salida desde un comando nativo. PowerShell no interpreta los datos redirigidos ni agrega ningún formato adicional. Para obtener más información, vea Ejemplo 7.
Ejemplos
Ejemplo 1: Redirigir errores y resultados a un archivo
Este ejemplo se ejecuta en un elemento que se ejecuta dir
correctamente y otro que produce un error.
dir C:\, fakepath 2>&1 > .\dir.log
Usa 2>&1
para redirigir el flujo de error a la secuencia Correcto y >
para enviar el flujo correcto resultante a un archivo denominadodir.log
Ejemplo 2: Envío de todos los datos de flujo correcto a un archivo
En este ejemplo se envían todos los datos de flujo correctos a un archivo denominado script.log
.
.\script.ps1 > script.log
Ejemplo 3: Envío correcto, advertencia y secuencias de error a un archivo
En este ejemplo se muestra cómo puede combinar operadores de redirección para lograr un resultado deseado.
&{
Write-Warning "hello"
Write-Error "hello"
Write-Output "hi"
} 3>&1 2>&1 > C:\Temp\redirection.log
3>&1
redirige la secuencia advertencia a la secuencia Correcto .2>&1
redirige el flujo Error a la secuencia Correcto (que ahora también incluye todos los datos de flujo de advertencia)>
redirige el flujo Correcto (que ahora contiene secuencias de advertencia y error ) a un archivo denominadoC:\temp\redirection.log
.
Ejemplo 4: Redirigir todas las secuencias a un archivo
En este ejemplo se envían todos los flujos de salida de un script llamado script.ps1
a un archivo denominado script.log
.
.\script.ps1 *> script.log
Ejemplo 5: Suprimir todos los datos de flujo de información y host de escritura
En este ejemplo se suprimen todos los datos del flujo de información. Para obtener más información sobre los cmdlets de flujo de información , consulte Write-Host y Write-Information.
&{
Write-Host "Hello"
Write-Information "Hello" -InformationAction Continue
} 6> $null
Ejemplo 6: Mostrar el efecto de las preferencias de acción
Las variables y parámetros de preferencias de acción pueden cambiar lo que se escribe en una secuencia determinada. El script de este ejemplo muestra cómo afecta el valor de $ErrorActionPreference
afecta a lo que se escribe en el flujo error .
$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'
Cuando se ejecuta este script, se le solicita cuando $ErrorActionPreference
se establece en Inquire
.
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.
Cuando examinamos el archivo de registro, vemos lo siguiente:
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
Ejemplo 7: Redireccionamiento de datos binarios desde un comando nativo
A partir de PowerShell 7.4, PowerShell conserva los datos de secuencia de bytes al redirigir la secuencia stdout de un comando nativo a un archivo o al canalización de datos de secuencia de bytes a la secuencia stdin de un comando nativo.
Por ejemplo, con el comando nativo curl
puede descargar un archivo binario y guardarlo en el disco mediante el redireccionamiento.
$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
También puede canalizar los datos de secuencia de bytes a la secuencia stdin de otro comando nativo. En el ejemplo siguiente se descarga un archivo TAR comprimido mediante curl
.
Los datos de archivo descargados se transmiten al comando tar
para extraer el contenido del archivo.
# native command output piped to a native command
curl -s -L $uri | tar -xzvf - -C .
También puede canalizar la salida de flujo de bytes de un comando de PowerShell a la entrada del comando nativo. En los ejemplos siguientes se usa Invoke-WebRequest
para descargar el mismo archivo TAR que el ejemplo anterior.
# 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 .
Esta característica no admite datos de secuencia de bytes al redirigir la salida stderr a stdout. Al combinar las secuencias stderr y stdout, las secuencias combinadas se tratan como datos de cadena.
Notas
Los operadores de redireccionamiento que no anexan datos (>
y n>
) sobrescriben el contenido actual del archivo especificado sin advertencia.
Sin embargo, si el archivo es de solo lectura, oculto o archivo del sistema, se produce un error en la redirección. Los operadores de redirección de anexión (>>
y n>>
) no escriben en un archivo de solo lectura, pero anexan contenido a un sistema o archivo oculto.
Para forzar la redirección del contenido a un archivo de sistema, oculto o de solo lectura, use el Out-File
cmdlet con su Force
parámetro .
Al escribir en archivos, los operadores de redireccionamiento usan UTF8NoBOM
codificación. Si el archivo tiene una codificación diferente, es posible que la salida no tenga el formato correcto. Para escribir en archivos con una codificación diferente, use el Out-File
cmdlet con su Encoding
parámetro .
Ancho de la salida al escribir en un archivo
Al escribir en un archivo mediante Out-File
o los operadores de redirección, PowerShell da formato a la salida de la tabla al archivo en función del ancho de la consola en la que se ejecuta. Por ejemplo, al registrar la salida de la tabla en el archivo mediante un comando como Get-ChildItem Env:\Path > path.log
en un sistema en el que el ancho de la consola se establece en 80 columnas, la salida del archivo se trunca en 80 caracteres:
Name Value
---- -----
Path C:\Program Files\PowerShell\7;C:\WINDOWS…
Teniendo en cuenta que el ancho de la consola puede establecerse arbitrariamente en sistemas en los que se ejecuta el script, es posible que prefiera que la salida de la tabla de formato de PowerShell a los archivos se basen en un ancho que especifique en su lugar.
El Out-File
cmdlet proporciona un parámetro Width que permite establecer el ancho que desea para la salida de la tabla. En lugar de tener que agregar -Width 2000
en cualquier lugar que invoque Out-File
, puede usar la $PSDefaultParameterValues
variable para establecer este valor para todos los usos del Out-File
cmdlet en un script. Y dado que los operadores de redireccionamiento (>
y >>
) son alias de forma eficaz para Out-File
, establecer el Out-File:Width
parámetro para todo el script afecta también al ancho de formato para los operadores de redirección. Coloque el siguiente comando cerca de la parte superior del script que se va a establecer Out-File:Width
para todo el script:
$PSDefaultParameterValues['out-file:width'] = 2000
Aumentar el ancho de salida aumentará el consumo de memoria al registrar la salida con formato de tabla. Si va a registrar muchos datos tabulares en el archivo y sabe que puede obtenerlo con un ancho menor, use el ancho más pequeño.
En algunos casos, como Get-Service
la salida, con el fin de usar el ancho adicional, deberá canalizar la salida antes de la salida Format-Table -AutoSize
al archivo.
$PSDefaultParameterValues['out-file:width'] = 2000
Get-Service | Format-Table -AutoSize > services.log
Para obtener más información sobre $PSDefaultParameterValues
, consulte about_Preference_Variables.
Posible confusión con operadores de comparación
El >
operador no debe confundirse con el operador de comparación Mayor que (a menudo se indica como >
en otros lenguajes de programación).
Dependiendo de los objetos que se comparan, la salida que usa >
puede parecer correcta (porque 36 no es mayor que 42).
PS> if (36 > 42) { "true" } else { "false" }
false
Sin embargo, una comprobación del sistema de archivos local puede ver que se escribió un archivo llamado 42
, con el contenido 36
.
PS> dir
Mode LastWriteTime Length Name
---- ------------- ------ ----
------ 1/02/20 10:10 am 3 42
PS> cat 42
36
Al intentar usar la comparación <
inversa (menor que), se produce un error del sistema:
PS> if (36 < 42) { "true" } else { "false" }
ParserError:
Line |
1 | if (36 < 42) { "true" } else { "false" }
| ~
| The '<' operator is reserved for future use.
Si la comparación numérica es la operación -lt
necesaria y -gt
se debe usar. Para obtener más información, consulte el -gt
operador en about_Comparison_Operators.
Consulte también
Comentarios
https://aka.ms/ContentUserFeedback.
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea:Enviar y ver comentarios de