Usar recursos experimentais no PowerShell
O suporte de recursos experimentais no PowerShell fornece um mecanismo para que os recursos experimentais coexistam com os recursos estáveis existentes nos módulos PowerShell ou PowerShell.
Um recurso experimental é aquele em que o design não está finalizado. O recurso está disponível para os usuários testarem e fornecerem comentários. Depois que um recurso experimental é finalizado, as alterações de design se tornam alterações interruptivas.
Cuidado
Os recursos experimentais não devem ser usados na produção, já que as alterações podem causar problemas. Recursos experimentais não têm suporte oficialmente. No entanto, agradecemos o envio de comentários e relatórios de bugs. Você pode arquivar problemas no repositório de origem do GitHub.
Para obter mais informações sobre como habilitar ou desabilitar esses recursos, confira about_Experimental_Features.
Ciclo de vida de recursos experimentais
O cmdlet Get-ExperimentalFeature retorna todos os recursos experimentais disponíveis para o PowerShell.
Os recursos experimentais podem vir de módulos ou do mecanismo do PowerShell. Os recursos experimentais baseados em módulos só estarão disponíveis após a importação do módulo. No exemplo a seguir, o PSDesiredStateConfiguration não está carregado, portanto, o recurso PSDesiredStateConfiguration.InvokeDscResource não está disponível.
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 os cmdlets Enable-ExperimentalFeature e Disable-ExperimentalFeature para habilitar ou desabilitar um recurso. Inicie uma nova sessão do PowerShell para que essa alteração entre em vigor. Execute o seguinte comando para habilitar o recurso PSCommandNotFoundSuggestion:
Enable-ExperimentalFeature PSCommandNotFoundSuggestion
WARNING: Enabling and disabling experimental features do not take effect until next start
of PowerShell.
Quando um recurso experimental se torna mainstream, ele não está mais disponível como um recurso experimental porque a funcionalidade agora faz parte do mecanismo ou módulo do PowerShell. Por exemplo, o recurso PSAnsiRenderingFileInfo tornou-se base no PowerShell 7.3. Você obtém a funcionalidade do recurso automaticamente.
Observação
Alguns recursos têm requisitos de configuração, como variáveis de preferência, que devem ser definidos para obter os resultados desejados desse recurso.
Quando um recurso experimental é descontinuado, esse recurso não estará mais disponível no PowerShell. Por exemplo, o recurso PSNativePSPathResolution foi descontinuado no PowerShell 7.3.
Recursos disponíveis
Este artigo descreve os recursos experimentais que estão disponíveis e como usar o recurso.
Legenda
- O ícone
indica que o recurso experimental está disponível na versão do PowerShell - O ícone
indica a versão do PowerShell em que o recurso experimental se tornou popular - O ícone
indica a versão do PowerShell da qual o recurso experimental foi removido
PSAnsiRenderingFileInfo
Observação
Esse recurso tornou-se base no PowerShell 7.3.
Os recursos de formatação ANSI foram adicionados no PowerShell 7.2. Esse recurso adiciona o membro $PSStyle.FileInfo e habilita a colorização de tipos de arquivo específicos.
$PSStyle.FileInfo.Directory- Membro interno para especificar a cor dos diretórios$PSStyle.FileInfo.SymbolicLink- Membro interno para especificar a cor dos links simbólicos$PSStyle.FileInfo.Executable- Membro interno para especificar a cor dos executáveis.$PSStyle.FileInfo.Extension- Use esse membro para definir as cores para diferentes as extensões de arquivo. O membro Extensão inclui previamente extensões para arquivos do PowerShell e da camada de armazenamento de arquivos.
Para obter mais informações, confira about_Automatic_Variables.
PSCommandNotFoundSuggestion
Observação
Essa funcionalidade tornou-se popular no PowerShell 7.5-preview.5.
Recomenda comandos potenciais com base na pesquisa de correspondência difusa após um 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
Observação
Essa funcionalidade tornou-se popular no PowerShell 7.5-preview.5.
Esse recurso habilita o parâmetro -CommandWithArgs para pwsh. Esse parâmetro permite executar um comando do PowerShell com argumentos. Ao contrário de -Command, esse parâmetro preenche a variável interna $args que pode ser usada pelo comando.
A primeira cadeia de caracteres é o comando e as cadeias de caracteres subsequentes delimitadas pelo espaço em branco são os argumentos.
Por exemplo:
pwsh -CommandWithArgs '$args | % { "arg: $_" }' arg1 arg2
Esse exemplo gera a saída a seguir:
arg: arg1
arg: arg2
Esse recurso foi adicionado no PowerShell 7.4.preview-2.
PSDesiredStateConfiguration.InvokeDscResource
Habilita a compilação para o formato MOF em sistemas que não são do Windows e permite o uso de Invoke-DSCResource sem um LCM.
A partir do PowerShell 7.2, o módulo PSDesiredStateConfiguration foi removido, e esse recurso está desabilitado por padrão. Para habilitar esse recurso, você deve instalar o módulo PSDesiredStateConfiguration v2.0.5 da Galeria do PowerShell e habilitar o recurso.
O DSC v3 não tem esse recurso experimental. O DSC v3 só dá suporte a Invoke-DSCResource e não usa nem dá suporte à compilação MOF. Para saber mais informações, confira PowerShell Desired State Configuration v3.
PSFeedbackProvider
Quando você habilita esse recurso, o PowerShell usa um novo provedor de comentários para fornecer comentários quando um comando não pode ser encontrado. O provedor de comentários é extensível e pode ser implementado por módulos de terceiros. O provedor de comentários pode ser usado por outros subsistemas, como o subsistema do preditor, para fornecer resultados preditivos do IntelliSense.
Esse recurso inclui dois provedores de comentários internos:
GeneralCommandErrorFeedback atende à mesma funcionalidade de sugestão existente hoje
UnixCommandNotFound, disponível no Linux, fornece comentários semelhantes ao bash.
O UnixCommandNotFound serve como um provedor de comentários e um preditor. A sugestão do comando command-not-found é usada para fornecer os comentários quando o comando não pode ser encontrado em uma execução interativa e para fornecer resultados preditivos do IntelliSense para a próxima linha de comando.
Esse recurso foi adicionado no PowerShell 7.4-preview.3.
PSLoadAssemblyFromNativeCode
Expõe uma API para permitir o carregamento de assembly do código nativo.
PSModuleAutoLoadSkipOfflineFiles
Observação
Essa funcionalidade tornou-se popular no PowerShell 7.5-preview.5.
Com esse recurso ativado, se o PSModulePath de um usuário contiver uma pasta de um provedor de nuvem, como o OneDrive, o PowerShell não acionará mais o download de todos os arquivos contidos nessa pasta. Qualquer arquivo marcado como não baixado é ignorado. Os usuários que usam provedores de nuvem para sincronizar seus módulos entre máquinas devem marcar a pasta do módulo como Fixada ou o status equivalente para provedores diferentes do OneDrive. Marcar a pasta do módulo como Fixada garante que os arquivos sejam sempre mantidos em disco.
Esse recurso foi adicionado no PowerShell 7.4-preview.1.
PSNativeCommandArgumentPassing
Observação
Esse recurso tornou-se base no PowerShell 7.3.
Quando esse recurso experimental estiver habilitado, o PowerShell usará a propriedade ArgumentList do objeto StartProcessInfo em vez do mecanismo atual de reconstrução de uma cadeia de caracteres ao invocar um executável nativo.
Cuidado
O novo comportamento é uma alteração interruptiva do comportamento atual. Isso pode interromper scripts e automação que solucionam os diversos problemas que ocorrem ao invocar aplicativos nativos. Historicamente, as aspas devem ser precedidas e não é possível fornecer argumentos vazios para um aplicativo nativo.
Use o token stop-parsing (--%) ou o cmdlet Start-Process para evitar que o argumento nativo passe quando necessário.
Esse recurso adiciona uma nova variável de preferência $PSNativeCommandArgumentPassing que controla esse comportamento. Essa variável permite que você selecione o comportamento em runtime. Os valores válidos são Legacy, Standard e Windows. O comportamento padrão é específico da plataforma. Em plataformas Windows, a configuração padrão é Windows e em plataformas não Windows a configuração padrão é Standard.
Legacy é o comportamento histórico. O comportamento dos modos Windows e Standard são os mesmos, exceto que, no modo Windows, as invocações dos arquivos a seguir usam automaticamente a passagem do argumento de estilo Legacy.
cmd.exefind.execscript.exewscript.exesqlcmd.exe– Adicionado no PowerShell 7.3.1- terminando com
.bat - terminando com
.cmd - terminando com
.js - terminando com
.vbs - terminando com
.wsf
Se o $PSNativeCommandArgumentPassing estiver definido como Legacy ou Standard, o analisador não verificará esses arquivos.
O comportamento padrão é específico da plataforma. Em plataformas Windows, a configuração padrão é Windows e plataformas não Windows são Standard.
Observação
Os exemplo a seguir usam a ferramenta TestExe.exe. Você pode criar TestExe com base no código-fonte.
Confira TestExe no repositório de origem do PowerShell.
Novos comportamentos disponibilizados por essa alteração:
Cadeias de caracteres literais ou expansíveis com aspas inseridas. As aspas são preservadas:
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>Cadeias de caracteres vazias usadas como argumentos são preservadas:
PS> TestExe -echoargs '' a b '' Arg 0 is <> Arg 1 is <a> Arg 2 is <b> Arg 3 is <>
Para obter mais exemplos do novo comportamento, confira about_Parsing.
O PowerShell 7.3 também adicionou a capacidade de rastrear a associação de parâmetros para comandos nativos. Para obter mais informações, confira Trace-Command.
PSNativeCommandErrorActionPreference
Observação
Esse recurso tornou-se predominante no PowerShell 7.4.
Os comandos nativos geralmente retornam um código de saída para o aplicativo de chamada que é zero para sucesso ou diferente de zero para falha. No entanto, os comandos nativos atualmente não participam do fluxo de erros do PowerShell. A saída stderr redirecionada não é interpretada da mesma forma que o fluxo de erro do PowerShell. Muitos comandos nativos usam stderr como uma informação ou um fluxo detalhado, portanto, apenas o código de saída é importante. Os usuários que trabalham com comandos nativos nos respectivos scripts precisam verificar o status de saída após cada chamada usando o seguinte exemplo semelhante:
if ($LASTEXITCODE -ne 0) {
throw "Command failed. See above errors for details"
}
No entanto, este exemplo não oferece suporte a todos os casos em que $? pode ser falso em um cmdlet ou erro de função, tornando $LASTEXITCODE obsoleto.
Esse recurso implementa a variável de preferência $PSNativeCommandUseErrorActionPreference que controla como os erros de comandos nativos são tratados no PowerShell. Isso permite que falhas de comando nativo produzam objetos de erro que são adicionados ao fluxo de erro do PowerShell e podem encerrar a execução do script sem manipulação extra.
$PSNativeCommandUseErrorActionPreference é definido como $false por padrão. Com a preferência definida para $true, você obtém o seguinte comportamento:
- Quando
$ErrorActionPreference = 'Stop', os scripts serão interrompidos quando um comando nativo retornar um código de saída diferente de zero. - Quando
$ErrorActionPreference = 'Continue'(o padrão), você verá mensagens de erro do PowerShell para erros de comando nativos, mas os scripts não serão interrompidos.
PSNativePSPathResolution
Observação
Este recurso experimental foi removido do PowerShell 7.3 e não tem mais suporte.
Se um caminho PSDrive que usa o provedor FileSystem for passado para um comando nativo, o caminho do arquivo resolvido será passado para o comando nativo. Isso significa que um comando como code temp:/test.txt agora funciona conforme o esperado.
Além disso, no Windows, se o demarcador começar com ~, isso será resolvido para o demarcador completo e passado para o comando nativo. Em ambos os casos, o caminho é normalizado para os separadores de diretório para o sistema operacional relevante.
- Se o demarcador não for um PSDrive ou
~(no Windows), a normalização do demarcador não ocorrerá - Se o caminho estiver entre aspas simples, ele não será resolvido e tratado como literal
PSRedirectToVariable
Observação
Esse recurso experimental foi introduzido no PowerShell 7.5-preview.4.
Quando habilitado, esse recurso adiciona suporte para redirecionamento para a unidade variável. Esse recurso permite redirecionar dados para uma variável usando a sintaxe variable:name. O PowerShell inspeciona o destino do redirecionamento e, se usar o provedor de variáveis, ele chamará Set-Variable em vez de Out-File.
O exemplo a seguir mostra como redirecionar a saída de um comando para uma variável:
. {
"Output 1"
Write-Warning "Warning, Warning!"
"Output 2"
} 3> variable:warnings
$warnings
Output 1
Output 2
WARNING: Warning, Warning!
PSSubsystemPluginModel
Esse recurso habilita o modelo de plug-in do subsistema no PowerShell. Ele possibilita a separação dos componentes de System.Management.Automation.dll em subsistemas individuais que residem no próprio assembly. Essa divisão reduz o volume de disco do mecanismo principal do PowerShell e permite que esses componentes se tornem recursos opcionais para uma instalação mínima do PowerShell.
Atualmente, há suporte apenas para o subsistema CommandPredictor. Esse subsistema é usado com o módulo PSReadLine para fornecer plug-ins de previsão personalizados. No futuro, será possível dividir Job, CommandCompleter, Remoting e outros componentes em assemblies de subsistema fora do System.Management.Automation.dll.
O recurso experimental inclui um novo cmdlet, o Get-PSSubsystem. Esse cmdlet só está disponível quando o recurso está habilitado. Esse cmdlet retorna informações sobre os subsistemas disponíveis no sistema.
PSNativeWindowsTildeExpansion
Quando esse recurso está habilitado, o PowerShell expande o til (~) sem aspas para a pasta inicial atual do usuário antes de invocar comandos nativos. Os exemplos a seguir mostram como o recurso funciona.
Com o recurso desabilitado, o til é passado para o comando nativo como uma cadeia de caracteres literal.
PS> cmd.exe /c echo ~
~
Com o recurso habilitado, o PowerShell expande o til antes de ser passado para o comando nativo.
PS> cmd.exe /c echo ~
C:\Users\username
Esse recurso se aplica apenas ao Windows. Em plataformas não Windows, a expansão do til é tratada nativamente.
Esse recurso foi adicionado no PowerShell 7.5-preview.2.
PSSerializeJSONLongEnumAsNumber
Esse recurso permite que o cmdlet ConvertTo-Json serialize quaisquer valores de enumeração com base em Int64/long ou UInt64/ulong como um valor numérico, em vez da representação da sequência desse valor de enumeração. Isso alinha o comportamento da serialização de enumeração com outros tipos-base de enumeração em que o cmdlet serializa enumerações como seu valor numérico. Use o parâmetro EnumsAsStrings para serializar como a representação da sequência.
Por exemplo:
# 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" }
