Compartir a través de


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…
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 Experimental indica que la característica experimental está disponible en la versión de PowerShell
  • El icono Mainstream indica la versión de PowerShell donde la característica experimental ya es estándar
  • El icono Discontinued indica la versión de PowerShell donde la característica experimental se ha eliminado
Nombre 7.2 7.3 7.4 7.5 (versión preliminar)
PSCommandNotFoundSuggestion Experimental Experimental Experimental Experimental
PSDesiredStateConfiguration.InvokeDscResource Experimental Experimental Experimental Experimental
PSNativePSPathResolution Experimental Descontinuado
PSSubsystemPluginModel Experimental Experimental Experimental Experimental
PSNativeCommandArgumentPassing Experimental Estándar
PSAnsiRenderingFileInfo Experimental Estándar
PSLoadAssemblyFromNativeCode Experimental Experimental Experimental Experimental
PSNativeCommandErrorActionPreference Experimental Estándar
PSFeedbackProvider Experimental Experimental
PSModuleAutoLoadSkipOfflineFiles Experimental Experimental
PSCommandWithArgs Experimental Experimental
PSNativeWindowsTildeExpansion Experimental

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

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

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

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.exe
  • find.exe
  • cscript.exe
  • wscript.exe
  • sqlcmd.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.

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.