Uso de características experimentales en PowerShell
La compatibilidad con las características experimentales de PowerShell proporciona un mecanismo para que las características experimentales coexistan con las características estables existentes en PowerShell o los módulos de PowerShell.
Una característica experimental es aquella en la que el diseño no ha finalizado. La característica está disponible para que los usuarios puedan probar y proporcionar comentarios. Una vez finalizada una característica experimental, los cambios de diseño se vuelven importantes.
Precaución
No está previsto que las características experimentales se usen en producción, ya que los cambios se pueden interrumpir. Las características experimentales no cuentan con soporte técnico oficial. Sin embargo, agradecemos los comentarios y los informes de errores. Puede informar de las incidencias en el repositorio de origen de GitHub.
Para obtener más información acerca de cómo habilitar o deshabilitar estas características, vea Acerca de las características experimentales.
Ciclo de vida de características experimentales
El cmdlet Get-ExperimentalFeature devuelve todas las características experimentales disponibles para PowerShell.
Las características experimentales pueden proceder de módulos o del motor de PowerShell. Las características experimentales basadas en módulos solo están disponibles después de importar el módulo. En el ejemplo siguiente, no se carga el PSDesiredStateConfiguration, por lo que la característica PSDesiredStateConfiguration.InvokeDscResource no está disponible.
Get-ExperimentalFeature
Name Enabled Source Description
---- ------- ------ -----------
PSCommandNotFoundSuggestion False PSEngine Recommend potential commands based on fuzzy searc…
PSCommandWithArgs False PSEngine Enable `-CommandWithArgs` parameter for pwsh
PSFeedbackProvider True PSEngine Replace the hard-coded suggestion framework with …
PSLoadAssemblyFromNativeCode False PSEngine Expose an API to allow assembly loading from nati…
PSModuleAutoLoadSkipOfflineFiles True PSEngine Module discovery will skip over files that are ma…
PSSerializeJSONLongEnumAsNumber True PSEngine Serialize enums based on long or ulong as an nume…
PSSubsystemPluginModel True PSEngine A plugin model for registering and un-registering…
Use los cmdlets Enable-ExperimentalFeature y Disable-ExperimentalFeature para habilitar o deshabilitar una característica. Debe iniciar una nueva sesión de PowerShell para que se aplique este cambio. Ejecute el siguiente comando para habilitar la característica PSCommandNotFoundSuggestion:
Enable-ExperimentalFeature PSCommandNotFoundSuggestion
WARNING: Enabling and disabling experimental features do not take effect until next start
of PowerShell.
Cuando una característica experimental se convierte en estándar, ya no está disponible como una característica experimental porque la funcionalidad ahora forma parte del motor o módulo de PowerShell. Por ejemplo, la característica PSAnsiRenderingFileInfo se convirtió en estándar en PowerShell 7.3. Obtiene automáticamente la funcionalidad de la característica.
Nota:
Algunas características tienen requisitos de configuración, como variables de preferencia, que deben establecerse para obtener los resultados deseados de la característica.
Cuando se interrumpe una característica experimental, esa característica ya no está disponible en PowerShell. Por ejemplo, la característica PSNativePSPathResolution se descontinuó en PowerShell 7.3.
Características disponibles
En este artículo se describen las características experimentales que están disponibles y cómo usarlas.
Leyenda
- El icono
indica que la característica experimental está disponible en la versión de PowerShell - El icono
indica la versión de PowerShell donde la característica experimental ya es estándar - El icono
indica la versión de PowerShell donde la característica experimental se ha eliminado
PSAnsiRenderingFileInfo
Nota
Esta característica se convirtió en estándar en PowerShell 7.3.
Las características de formato ANSI se agregaron en PowerShell 7.2. Esta característica agrega el miembro $PSStyle.FileInfo y permite colorear tipos de archivo específicos.
$PSStyle.FileInfo.Directory: miembro integrado para especificar el color de los directorios$PSStyle.FileInfo.SymbolicLink: miembro integrado para especificar el color de los vínculos simbólicos$PSStyle.FileInfo.Executable: miembro integrado para especificar el color de los ejecutables.$PSStyle.FileInfo.Extension: use este miembro para definir colores para diferentes extensiones de archivo. El miembro Extension incluye previamente extensiones para archivar y para archivos de PowerShell.
Para obtener más información, vea about_Automatic_Variables.
PSCommandNotFoundSuggestion
Nota:
Esta característica se convirtió en estándar en PowerShell 7.5.preview.5.
Recomienda comandos potenciales basados en la búsqueda de coincidencias aproximadas después de CommandNotFoundException.
PS> get
get: The term 'get' isn't recognized as the name of a cmdlet, function, script file,
or operable program. Check the spelling of the name, or if a path was included, verify
that the path is correct and try again.
Suggestion [4,General]: The most similar commands are: set, del, ft, gal, gbp, gc, gci,
gcm, gdr, gcs.
PSCommandWithArgs
Nota:
Esta característica se convirtió en estándar en PowerShell 7.5.preview.5.
Esta característica habilita el parámetro -CommandWithArgs para pwsh. Este parámetro permite ejecutar un comando de PowerShell con argumentos. A diferencia de -Command, este parámetro rellena la variable integrada $args que el comando puede usar.
La primera cadena es el comando y las cadenas subsiguientes delimitadas por espacios en blanco son los argumentos.
Por ejemplo:
pwsh -CommandWithArgs '$args | % { "arg: $_" }' arg1 arg2
Este ejemplo produce el siguiente resultado:
arg: arg1
arg: arg2
Esta característica se agregó en PowerShell 7.4.preview.2.
PSDesiredStateConfiguration.InvokeDscResource
Habilita la compilación en MOF en sistemas que no son de Windows y permite el uso de Invoke-DSCResource sin LCM.
A partir de PowerShell 7.2, se quitó el módulo PSDesiredStateConfiguration y esta característica está deshabilitada de manera predeterminada. Para habilitar esta característica, debe instalar el módulo PSDesiredStateConfiguration v2.0.5 desde la Galería de PowerShell y habilitarla.
DSC v3 no tiene esta característica experimental. DSC v3 solo admite Invoke-DSCResource y no usa ni admite la compilación MOF. Para obtener más información, vea Desired State Configuration v3 de PowerShell.
PSFeedbackProvider
Al habilitar esta característica, PowerShell usa un nuevo proveedor de comentarios para proporcionarle comentarios cuando no se encuentra un comando. El proveedor de comentarios es extensible y se puede implementar mediante módulos de terceros. Otros subsistemas, como el subsistema de predicción, pueden usar el proveedor de comentarios para proporcionar resultados predictivos de IntelliSense.
Esta característica incluye dos proveedores de comentarios integrados:
GeneralCommandErrorFeedback sirve para la misma funcionalidad de sugerencia existente en la actualidad
UnixCommandNotFound, disponible en Linux, proporciona comentarios similares a Bash.
UnixCommandNotFound actúa como proveedor de comentarios y un predictor. La sugerencia del comando no encontrado se usa para proporcionar los comentarios cuando el comando no se encuentra en una ejecución interactiva y para proporcionar resultados predictivos de IntelliSense para la siguiente línea de comandos.
Esta característica se agregó en PowerShell 7.4-preview.3.
PSLoadAssemblyFromNativeCode
Expone una API para permitir la carga de ensamblados desde código nativo.
PSModuleAutoLoadSkipOfflineFiles
Nota:
Esta característica se convirtió en estándar en PowerShell 7.5.preview.5.
Con esta característica habilitada, si PSModulePath de un usuario contiene una carpeta de un proveedor de nube, como OneDrive, PowerShell ya no desencadena la descarga de todos los archivos contenidos en esa carpeta. Se omite cualquier archivo marcado como no descargado. Los usuarios que usan proveedores de nube para sincronizar sus módulos entre máquinas deben marcar la carpeta de módulos como Anclada o en el estado equivalente para proveedores distintos de OneDrive. Al marcar la carpeta de módulos como Anclada se garantiza que los archivos siempre se mantienen en el disco.
Esta característica se agregó en PowerShell 7.4-preview.1.
PSNativeCommandArgumentPassing
Nota
Esta característica se convirtió en estándar en PowerShell 7.3.
Cuando esta característica experimental está habilitada, PowerShell usa la propiedad ArgumentList del objeto StartProcessInfo en lugar de nuestro mecanismo actual de reconstrucción de una cadena al invocar un ejecutable nativo.
Precaución
Este nuevo comportamiento supone un cambio importante respecto al comportamiento actual. Puede provocar la interrupción de los scripts y la automatización que se usan como soluciones alternativas para diferentes problemas al invocar aplicaciones nativas. Hasta ahora, las comillas debían escaparse, y no es posible proporcionar argumentos vacíos a una aplicación nativa.
Use el token stop-parsing (--%) o el cmdlet para omitir el Start-Process paso de argumentos nativos cuando sea necesario.
Esta característica agrega una nueva variable de preferencia $PSNativeCommandArgumentPassing que controla este comportamiento. Esta variable permite seleccionar el comportamiento durante el runtime. Los valores válidos son Legacy, Standard y Windows. El comportamiento predeterminado es específico de cada plataforma. En plataformas Windows la configuración predeterminada es Windows y las plataformas no Windows adoptan el valor predeterminado Standard.
Legacy es el comportamiento que se ha usado hasta ahora. El comportamiento de los modos Windows y Standard es el mismo con la excepción de que, en modo Windows, las invocaciones de los archivos siguientes usan automáticamente el paso de argumentos de estilo Legacy.
cmd.exefind.execscript.exewscript.exesqlcmd.exe- Agregado en PowerShell 7.3.1- termina en
.bat - termina en
.cmd - termina en
.js - termina en
.vbs - termina en
.wsf
Si $PSNativeCommandArgumentPassing se establece en Legacy o Standard, el analizador no comprueba estos archivos.
El comportamiento predeterminado es específico de cada plataforma. En plataformas Windows la configuración predeterminada es Windows y en plataformas no Windows Standard.
Nota
Los ejemplos siguientes usan la herramienta TestExe.exe. Puede compilar TestExe a partir del código fuente.
Consulte TestExe en el repositorio de origen de PowerShell.
Nuevos comportamientos disponibles con este cambio:
Las cadenas literales o expandibles con comillas insertadas se conservan:
PS> $a = 'a" "b' PS> TestExe -echoargs $a 'c" "d' e" "f Arg 0 is <a" "b> Arg 1 is <c" "d> Arg 2 is <e f>Las cadenas vacías usadas como argumentos se conservan:
PS> TestExe -echoargs '' a b '' Arg 0 is <> Arg 1 is <a> Arg 2 is <b> Arg 3 is <>
Para obtener más ejemplos del nuevo comportamiento, consulte about_Parsing.
PowerShell 7.3 también agregó la capacidad de realizar un seguimiento del enlace de parámetros para comandos nativos. Para más información, vea Trace-Command.
PSNativeCommandErrorActionPreference
Nota:
Esta característica se convirtió en estándar en PowerShell 7.4.
Los comandos nativos normalmente devuelven un código de salida a la aplicación que realiza la llamada, que es de cero en caso de éxito o distinto de cero en caso de error. Sin embargo, los comandos nativos no participan actualmente en el flujo de errores de PowerShell. La salida redirigida de stderr no se interpreta de la misma forma que el flujo de errores de PowerShell. Muchos comandos nativos usan stderr como un flujo de información o detallado, por lo que solo importa el código de salida. Los usuarios que trabajan con comandos nativos en sus scripts deben comprobar el estado de salida después de cada llamada con un ejemplo similar al siguiente:
if ($LASTEXITCODE -ne 0) {
throw "Command failed. See above errors for details"
}
Sin embargo, este ejemplo no admite todos los casos en los que $? puede ser "false" procedente de un error de cmdlet o de función, lo que hace que $LASTEXITCODE sea obsoleto.
Esta característica implementa la variable de preferencia $PSNativeCommandUseErrorActionPreference que controla cómo se controlan los errores de comandos nativos en PowerShell. De esta forma, los errores de comandos nativos producen objetos de error que se agregan al flujo de errores de PowerShell y puede terminar la ejecución del script sin control adicional.
$PSNativeCommandUseErrorActionPreference se establece en $false de forma predeterminada. Con la preferencia establecida en $true, se obtiene el siguiente comportamiento:
- Cuando
$ErrorActionPreference = 'Stop', los scripts se interrumpirán cuando un comando nativo devuelva un código de salida distinto de cero. - Cuando
$ErrorActionPreference = 'Continue'(opción predeterminada), verá mensajes de error de PowerShell para errores de comandos nativos, pero los scripts no se interrumpirán.
PSNativePSPathResolution
Nota:
Esta característica experimental se quitó en PowerShell 7.3 y ya no se admite.
Si una ruta de acceso de PSDrive que usa el proveedor de sistema de archivos se pasa a un comando nativo, la ruta de acceso del archivo resuelta se pasa al comando nativo. Esto significa que un comando como code temp:/test.txt funciona ahora como se esperaba.
Además, en Windows, si la ruta de acceso comienza con ~, se resuelve en la ruta de acceso completa y se pasa al comando nativo. En ambos casos, la ruta de acceso se normaliza en los separadores de directorio para el sistema operativo correspondiente.
- Si la ruta de acceso no es un parámetro PSDrive o
~(en Windows), no se produce la normalización de la ruta de acceso. - Si la ruta de acceso está entre comillas simples, no se resuelve y se trata como literal.
PSRedirectToVariable
Nota:
Esta característica experimental se agregó en PowerShell 7.5-preview.4.
Cuando está habilitada, esta característica agrega compatibilidad para redirigir a la unidad variable. Esta característica permite redirigir los datos a una variable mediante la sintaxis variable:name. PowerShell inspecciona el destino del redireccionamiento y, si usa el proveedor de variables, llama a Set-Variable en lugar de a Out-File.
En el ejemplo siguiente se muestra cómo redirigir la salida de un comando en una variable:
. {
"Output 1"
Write-Warning "Warning, Warning!"
"Output 2"
} 3> variable:warnings
$warnings
Output 1
Output 2
WARNING: Warning, Warning!
PSSubsystemPluginModel
Esta característica habilita el modelo de complemento de subsistema en PowerShell. La característica permite separar componentes de System.Management.Automation.dll en subsistemas individuales que residen en su propio ensamblado. Esta separación reduce la superficie de memoria del disco del motor de PowerShell principal y permite que estos componentes se conviertan en características opcionales para una instalación mínima de PowerShell.
Actualmente, solo se admite el subsistema CommandPredictor. Este subsistema se usa junto con el módulo PSReadLine para proporcionar complementos de predicción personalizados. En el futuro, Job, CommandCompleter, Remoting y otros componentes podrían separarse en ensamblados de subsistema fuera de System.Management.Automation.dll.
La característica experimental incluye un nuevo cmdlet, Get-PSSubsystem. Este cmdlet solo está disponible cuando la característica está habilitada y devuelve información sobre los subsistemas que están disponibles en el sistema.
PSNativeWindowsTildeExpansion
Cuando esta característica está habilitada, PowerShell expande la tilde sin comillas (~) a la carpeta principal actual del usuario antes de invocar comandos nativos. En los ejemplos siguientes se muestra cómo funciona la característica.
Con la característica deshabilitada, la tilde se pasa al comando nativo como una cadena literal.
PS> cmd.exe /c echo ~
~
Con la característica habilitada, PowerShell expande la tilde antes de pasarla al comando nativo.
PS> cmd.exe /c echo ~
C:\Users\username
Esta característica solo se aplica a Windows. En plataformas que no son Windows, la expansión de tilde se controla de forma nativa.
Esta característica se ha agregado en PowerShell 7.5-preview.2.
PSSerializeJSONLongEnumAsNumber
Esta característica permite al cmdlet ConvertTo-Json serializar los valores de enumeración basados en Int64/long o UInt64/ulong como un valor numérico en lugar de la representación de cadena de ese valor de enumeración. Esto alinea el comportamiento de la serialización de enumeración con otros tipos base de enumeración donde el cmdlet serializa las enumeraciones como su valor numérico. Use el parámetro EnumsAsStrings para serializar como representación de la cadena.
Por ejemplo:
# PSSerializeJSONLongEnumAsNumber disabled
@{
Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json
# { "Key": "Cmdlets" }
# PSSerializeJSONLongEnumAsNumber enabled
@{
Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json
# { "Key": 32 }
# -EnumsAsStrings to revert back to the old behaviour
@{
Key = [System.Management.Automation.Tracing.PowerShellTraceKeywords]::Cmdlets
} | ConvertTo-Json -EnumsAsStrings
# { "Key": "Cmdlets" }
