Usando recursos experimentais no PowerShell
O suporte a 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 projeto não é finalizado. O recurso está disponível para os usuários testarem e fornecerem feedback. Uma vez que um recurso experimental é finalizado, as mudanças de design tornam-se mudanças de rutura.
Atenção
Os recursos experimentais não se destinam a ser usados na produção, uma vez que as mudanças podem ser quebradas. Recursos experimentais não são oficialmente suportados. No entanto, agradecemos qualquer feedback 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, consulte about_Experimental_Features.
Ciclo de vida do recurso experimental
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ódulo só estão disponíveis após a importação do módulo. No exemplo a seguir, o PSDesiredStateConfiguration não está carregado, portanto, o PSDesiredStateConfiguration.InvokeDscResource recurso 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. Você deve iniciar uma nova sessão do PowerShell para que essa alteração entre em vigor. Execute o seguinte comando para habilitar o PSCommandNotFoundSuggestion recurso:
Enable-ExperimentalFeature PSCommandNotFoundSuggestion
WARNING: Enabling and disabling experimental features do not take effect until next start
of PowerShell.
Quando um recurso experimental se torna comum, 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 PSAnsiRenderingFileInfo recurso tornou-se mainstream no PowerShell 7.3. Você obtém a funcionalidade do recurso automaticamente.
Nota
Alguns recursos têm requisitos de configuração, como variáveis de preferência, que devem ser definidos para obter os resultados desejados do recurso.
Quando um recurso experimental é descontinuado, esse recurso não está mais disponível no PowerShell. Por exemplo, o recurso foi descontinuado PSNativePSPathResolution no PowerShell 7.3.
Funcionalidades disponíveis
Este artigo descreve os recursos experimentais disponíveis e como usá-los.
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 mainstream - O
ícone indica a versão do PowerShell onde o recurso experimental foi removido
PSAnsiRenderingFileInfo
Nota
Esse recurso tornou-se mainstream no PowerShell 7.3.
Os recursos de formatação ANSI foram adicionados no PowerShell 7.2. Esse recurso adiciona o $PSStyle.FileInfo membro e permite colorir tipos de arquivos específicos.
$PSStyle.FileInfo.Directory- Membro embutido para especificar a cor para diretórios$PSStyle.FileInfo.SymbolicLink- Membro embutido para especificar a cor para links simbólicos$PSStyle.FileInfo.Executable- Membro embutido para especificar a cor para executáveis.$PSStyle.FileInfo.Extension- Use este membro para definir as cores para diferentes extensões de arquivo. O membro Extension pré-inclui extensões para arquivos morto e PowerShell.
Para obter mais informações, consulte about_Automatic_Variables.
PSCommandNotFoundSuggestion
Nota
Esse recurso tornou-se corrente 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
Nota
Esse recurso tornou-se corrente no PowerShell 7.5-preview.5.
Esse recurso habilita o -CommandWithArgs parâmetro para pwsh. Esse parâmetro permite executar um comando do PowerShell com argumentos. Ao contrário -Commanddo , esse parâmetro preenche a $args variável interna que pode ser usada pelo comando.
A primeira cadeia de caracteres é o comando e as cadeias subsequentes delimitadas por espaço em branco são os argumentos.
Por exemplo:
pwsh -CommandWithArgs '$args | % { "arg: $_" }' arg1 arg2
Este exemplo produz a seguinte saída:
arg: arg1
arg: arg2
Esse recurso foi adicionado no PowerShell 7.4-preview.2.
PSDesiredStateConfiguration.InvokeDscResource
Permite a compilação para MOF em sistemas não-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. DSC v3 suporta apenas Invoke-DSCResource e não usa ou suporta compilação MOF. Para obter mais informações, consulte Configuração de estado desejado do PowerShell 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 feedback é extensível e pode ser implementado por módulos de terceiros. O provedor de feedback pode ser usado por outros subsistemas, como o subsistema de predição, para fornecer resultados preditivos do IntelliSense.
Esta funcionalidade inclui dois fornecedores de feedback incorporados:
GeneralCommandErrorFeedback serve a mesma funcionalidade de sugestão existente hoje
UnixCommandNotFound, disponível no Linux, fornece feedback semelhante ao bash.
O UnixCommandNotFound serve como um provedor de feedback e um preditor. A sugestão do comando command-not-found é usada para fornecer o feedback 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 a partir de código nativo.
PSModuleAutoLoadSkipOfflineFiles
Nota
Esse recurso tornou-se corrente no PowerShell 7.5-preview.5.
Com esse recurso habilitado, 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 Fixo ou o status equivalente para provedores que não sejam o OneDrive. Marcar a pasta do módulo como Fixo garante que os arquivos sejam sempre mantidos no disco.
Esse recurso foi adicionado no PowerShell 7.4-preview.1.
PSNativeCommandArgumentPassing
Nota
Esse recurso tornou-se mainstream no PowerShell 7.3.
Quando esse recurso experimental é habilitado, o StartProcessInfo PowerShell usa a ArgumentList propriedade do objeto em vez de nosso mecanismo atual de reconstrução de uma cadeia de caracteres ao invocar um executável nativo.
Atenção
O novo comportamento é uma mudança de rutura em relação ao comportamento atual. Isso pode quebrar scripts e automação que contornam os vários problemas ao invocar aplicativos nativos. Historicamente, as citações devem ser evitadas e não é possível fornecer argumentos vazios para um aplicativo nativo.
Use o token de análise de parada (--%) ou o cmdlet para evitar a Start-Process passagem de argumentos nativos quando necessário.
Esse recurso adiciona uma nova $PSNativeCommandArgumentPassing variável de preferência que controla esse comportamento. Essa variável permite que você selecione o comportamento em tempo de execução. Os valores válidos são Legacy, Standarde Windows. O comportamento padrão é específico da plataforma. Em plataformas Windows, a configuração padrão é Windows e plataformas não-Windows padrão para Standard.
Legacy é o comportamento histórico. O comportamento de Windows e Standard modo são os mesmos, exceto, no Windows modo, invocações dos seguintes arquivos usam automaticamente o Legacy argumento style passando.
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 um 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 é Standard.
Nota
Os exemplos a seguir usam a TestExe.exe ferramenta. Você pode construir TestExe a partir do código-fonte.
Consulte TestExe no repositório de origem do PowerShell.
Novos comportamentos disponibilizados por esta alteração:
Strings literais ou expansíveis com aspas incorporadas 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 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, consulte about_Parsing.
O PowerShell 7.3 também adicionou a capacidade de rastrear a vinculação de parâmetros para comandos nativos. Para obter mais informações, consulte Trace-Command.
PSNativeCommandErrorActionPreference
Nota
Esse recurso tornou-se popular no PowerShell 7.4.
Os comandos nativos geralmente retornam um código de saída para o aplicativo de chamada que é zero para êxito ou diferente de zero para falha. No entanto, os comandos nativos atualmente não participam do fluxo de erro 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 um fluxo de informações ou detalhado, portanto, apenas o código de saída importa. Os usuários que trabalham com comandos nativos em seus scripts precisam verificar o status de saída após cada chamada usando semelhante ao exemplo a seguir:
if ($LASTEXITCODE -ne 0) {
throw "Command failed. See above errors for details"
}
No entanto, este exemplo não suporta todos os casos em que $? pode ser falso de um erro de cmdlet ou função, tornando-o $LASTEXITCODE obsoleto.
Esse recurso implementa a variável de preferência que controla como os $PSNativeCommandUseErrorActionPreference 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ê obter 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 nativo, mas os scripts não serão quebrados.
PSNativePSPathResolution
Nota
Esse recurso experimental foi removido no PowerShell 7.3 e não é mais suportado.
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 caminho começar com ~, isso será resolvido para o caminho 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 caminho não for um PSDrive ou
~(no Windows), a normalização do caminho não ocorrerá - Se o caminho estiver entre aspas simples, ele não será resolvido e tratado como literal
PSRedirectToVariable
Nota
Esse recurso experimental foi adicionado no PowerShell 7.5-preview.4.
Quando ativado, esse recurso adiciona suporte para redirecionamento para a unidade variável. Esse recurso permite redirecionar dados para uma variável usando a variable:name sintaxe. O PowerShell inspeciona o destino do redirecionamento e, se ele usa o provedor de variáveis que chama 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. O recurso torna possível separar componentes de System.Management.Automation.dll subsistemas individuais que residem em sua própria montagem. Essa separação reduz o espaço ocupado pelo disco do mecanismo principal do PowerShell e permite que esses componentes se tornem recursos opcionais para uma instalação mínima do PowerShell.
Atualmente, apenas o subsistema CommandPredictor é suportado. Este subsistema é usado junto com o módulo PSReadLine para fornecer plug-ins de previsão personalizados. No futuro, Job, CommandCompleter, Remoting e outros componentes poderiam ser separados em montagens de subsistemas fora do System.Management.Automation.dll.
O recurso experimental inclui um novo cmdlet, Get-PSSubsystem. Esse cmdlet só está disponível quando o recurso está habilitado. Este cmdlet retorna informações sobre os subsistemas disponíveis no sistema.
PSNativeWindowsTildeExpansion
Quando esse recurso está habilitado, o PowerShell expande til não citado (~) para a pasta base atual do usuário antes de invocar comandos nativos. Os exemplos a seguir mostram como o recurso funciona.
Com o recurso desativado, 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
Esta funcionalidade aplica-se apenas ao Windows. Em plataformas que não sejam Windows, a expansão tilde é 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 enum com base em Int64/long ou como um valor numérico em vez UInt64/ulong da representação de cadeia de caracteres desse valor de enum. Isso alinha o comportamento da serialização de enum com outros tipos de base de enum, onde o cmdlet serializa enums como seu valor numérico. Use o EnumsAsStrings parâmetro para serializar como a representação de cadeia de caracteres.
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" }
