Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Windows PowerShell 5.1 je založený na rozhraní .NET Framework verze 4.5. Ve verzi PowerShellu 6.0 se PowerShell stal opensourcovým projektem založeným na .NET Core 2.0. Přechod z rozhraní .NET Framework na .NET Core umožnil PowerShellu stát se multiplatformním řešením. PowerShell běží ve Windows, macOS a Linuxu.
V jazyce PowerShell mezi Windows PowerShell a PowerShellem je málo rozdílů. Nejdůležitější rozdíly jsou v dostupnosti a chování rutin PowerShellu mezi platformami Windows a jinými systémy než Windows a změnami, které vyplývají z rozdílů mezi rozhraním .NET Framework a .NET Core.
Tento článek shrnuje významné rozdíly a zásadní změny prostředí Windows PowerShell a aktuální verze PowerShellu. Tento souhrn neobsahuje nové funkce ani rutiny, které byly přidány. Ani tento článek nepojedná o tom, co se mezi verzemi změnilo. Cílem tohoto článku je představit současný stav PowerShellu a to, jak se liší od Windows PowerShell. Podrobnou diskuzi o změnách mezi verzemi a přidáním nových funkcí najdete v článcích Co je nového pro každou verzi.
- Novinky v PowerShellu 7.5
- Novinky v PowerShellu 7.4
- Novinky v PowerShellu 7.3
- Novinky v PowerShellu 7.2
- Novinky v PowerShellu 7.1
- Novinky v PowerShellu 7.0
- Novinky v PowerShellu 6.x
.NET Framework vs. .NET Core
PowerShell v Linuxu a macOS používá .NET Core, což je podmnožina úplného rozhraní .NET Framework v systému Microsoft Windows. To je důležité, protože PowerShell poskytuje přímý přístup k základním typům a metodám architektury. V důsledku toho se skripty, které běží ve Windows, nemusí spouštět na platformách jiných než Windows kvůli rozdílům v architekturách. Další informace o změnách v .NET Core najdete v tématu Zásadní změny migrace z rozhraní .NET Framework na .NET Core.
Každá nová verze PowerShellu je založená na novější verzi .NET. V .NET může dojít k zásadním změnám, které mají vliv na PowerShell.
- PowerShell 7.6 – postaveno na .NET 10.0 (LTS)
- PowerShell 7.5 – postaveno na .NET 9.0
- PowerShell 7.4 – postaveno na .NET 8.0 (LTS)
- PowerShell 7.3 – postaveno na .NET 7.0
- PowerShell 7.2 – postaveno na .NET 6.0 (LTS)
- PowerShell 7.1 – postaveno na .NET 5.0
- PowerShell 7.0 – postaveno na .NET Core 3.1 (LTS)
- PowerShell 6.2 – postaveno na .NET Core 2.1
- PowerShell 6.1 – postaveno na .NET Core 2.1
- PowerShell 6.0 – postaveno na .NET Core 2.0
Po nástupu .NET Standard 2.0 může PowerShell načíst mnoho tradičních modulů Windows PowerShellu beze změny. PowerShell 7 navíc obsahuje funkci kompatibility prostředí Windows PowerShell, která umožňuje používat moduly Windows PowerShellu, které stále vyžadují úplnou architekturu.
Další informace najdete tady:
Mějte na paměti změny metod .NET.
I když změny metod .NET nejsou specifické pro PowerShell, můžou ovlivnit vaše skripty, zejména pokud voláte přímo metody .NET. Navíc mohou existovat nová přetížení pro konstruktory. To může mít vliv na způsob vytváření objektů pomocí New-Object nebo [type]::new() metody.
Například rozhraní .NET přidalo přetížení do [System.String]::Split() metody, které nejsou k dispozici v rozhraní .NET Framework 4.5. Následující seznam ukazuje přetížení metody Split() dostupné v prostředí Windows PowerShell 5.1:
PS> "".Split
OverloadDefinitions
-------------------
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)
Následující seznam ukazuje přetížení metody Split() dostupné v PowerShellu 7:
"".Split
OverloadDefinitions
-------------------
string[] Split(char separator, System.StringSplitOptions options)
string[] Split(char separator, int count, System.StringSplitOptions options)
string[] Split(Params char[] separator)
string[] Split(char[] separator, int count)
string[] Split(char[] separator, System.StringSplitOptions options)
string[] Split(char[] separator, int count, System.StringSplitOptions options)
string[] Split(string separator, System.StringSplitOptions options)
string[] Split(string separator, int count, System.StringSplitOptions options)
string[] Split(string[] separator, System.StringSplitOptions options)
string[] Split(string[] separator, int count, System.StringSplitOptions options)
Ve Windows PowerShellu 5.1 jste mohli metodě Split() předat znakové pole (char[]) jako string. Metoda rozdělí cílový řetězec v libovolném výskytu znaku v poli. Následující příkaz rozdělí cílový řetězec ve Windows PowerShellu 5.1, ale ne v PowerShellu 7:
# PowerShell 7 example
"1111p2222q3333".Split('pq')
1111p2222q3333
Chcete-li vytvořit vazbu na správné přetížení, je nutné přetypovat řetězec na pole znaků:
# PowerShell 7 example
"1111p2222q3333".Split([char[]]'pq')
1111
2222
3333
Moduly se už nedoručují pomocí PowerShellu
Z různých důvodů kompatibility už nejsou v PowerShellu zahrnuté následující moduly.
- ISE
- Microsoft.PowerShell.LocalAccounts
- Microsoft.PowerShell.ODataUtils
- Microsoft.PowerShell.Operation.Validation
- PSScheduledJob
- PSWorkflow
- PSWorkflowUtility
Pracovní postup PowerShellu
PowerShell Workflow je funkce ve Windows PowerShell, která navazuje na Windows Workflow Foundation (WF) a umožňuje vytvářet robustní runbooky pro dlouhodobě běžící nebo paralelizované úkoly.
Kvůli tomu, že .NET Core nepodporuje Windows Workflow Foundation, jsme odstranili PowerShell Workflow z PowerShellu.
V budoucnu bychom chtěli povolit nativní paralelismus a souběžnost v jazyce PowerShellu bez nutnosti používat pracovní postup PowerShellu.
Pokud je potřeba po restartování operačního systému obnovit skript pomocí kontrolních bodů, doporučujeme použít plánovač úloh ke spuštění skriptu při spuštění operačního systému, ale skript by si potřeboval zachovat svůj vlastní stav (například jeho uchování do souboru).
Cmdlets odebrané z PowerShellu
Pro moduly, které jsou součástí PowerShellu, byly z PowerShellu z různých důvodů kompatibility nebo použití nepodporovaných rozhraní API odebrány následující rutiny.
CimCmdlets
Export-BinaryMiLog
Microsoft.PowerShell.Core
Add-PSSnapinExport-ConsoleGet-PSSnapinRemove-PSSnapinResume-JobSuspend-Job
Microsoft.PowerShell.Diagnostics
Export-CounterImport-Counter
Microsoft.PowerShell.Management
Add-ComputerCheckpoint-ComputerClear-EventLogComplete-TransactionDisable-ComputerRestoreEnable-ComputerRestoreGet-ComputerRestorePointGet-ControlPanelItemGet-EventLogGet-TransactionGet-WmiObjectInvoke-WmiMethodLimit-EventLogNew-EventLogNew-WebServiceProxyRegister-WmiEventRemove-ComputerRemove-EventLogRemove-WmiObjectReset-ComputerMachinePasswordRestore-ComputerSet-WmiInstanceShow-ControlPanelItemShow-EventLogStart-TransactionTest-ComputerSecureChannelUndo-TransactionUse-TransactionWrite-EventLog
Microsoft.PowerShell.Utility
Convert-StringConvertFrom-String
PSDesiredStateConfiguration
Disable-DscDebugEnable-DscDebugGet-DscConfigurationGet-DscConfigurationStatusGet-DscLocalConfigurationManagerPublish-DscConfigurationRemove-DscConfigurationDocumentRestore-DscConfigurationSet-DscLocalConfigurationManagerStart-DscConfigurationStop-DscConfigurationTest-DscConfigurationUpdate-DscConfiguration
Rutiny rozhraní WMI v1
Z PowerShellu byly odebrány následující rutiny rozhraní WMI v1:
Register-WmiEventSet-WmiInstanceInvoke-WmiMethodGet-WmiObjectRemove-WmiObject
Rutiny modulu CimCmdlets (neboli WMI v2) provádějí stejnou funkci a poskytují nové funkce a přepracovanou syntaxi.
New-WebServiceProxy CMDLET odstraněn
.NET Core nepodporuje rozhraní Windows Communication Framework, které poskytuje služby pro použití protokolu SOAP. Tato rutina byla odebrána, protože vyžaduje protokol SOAP.
*-Transaction CMDLETS odstraněny
Tyto rutiny měly velmi omezené využití. Rozhodli jsme se ukončit podporu pro ně.
Complete-TransactionGet-TransactionStart-TransactionUndo-TransactionUse-Transaction
*-EventLog rutiny
Kvůli použití nepodporovaných rozhraní API byly *-EventLog cmdlety odebrány z PowerShellu.
Get-WinEvent a New-WinEvent jsou dostupné pro získávání a vytváření událostí na Windows.
Cmdlety, které používají Windows Presentation Framework (WPF)
.NET Core 3.1 přidala podporu pro WPF, takže verze PowerShellu 7.0 obnovila následující funkce specifické pro Windows:
- Cmdlet
Show-Command - Cmdlet
Out-GridView - Parametr ShowWindow pro
Get-Help
Změny konfigurace požadovaného stavu PowerShellu (DSC)
Invoke-DscResource byla obnovena jako experimentální funkce v PowerShellu 7.0.
Počínaje PowerShellem 7.2 byl modul PSDesiredStateConfiguration odstraněn z PowerShellu a byl publikován do galerie PowerShell. Další informace najdete v oznámení na blogu týmu PowerShellu.
Spustitelné změny PowerShellu
Přejmenování powershell.exe na pwsh.exe
Binární název powershellu byl změněn z powershell(.exe) na pwsh(.exe). Tato změna poskytuje deterministický způsob, jak uživatelé spouštět PowerShell na počítačích a podporovat souběžné instalace Windows PowerShellu a PowerShellu.
Další změny z pwsh(.exe)powershell.exe:
- První polohový parametr byl změněn z
-Commandna .-FileTato změna opravuje použití (#!tzv. jako shebang) v PowerShell skriptech, které jsou spouštěny z ne-PowerShell shellů na platformách mimo Windows. Také to znamená, že můžete spouštět příkazy jako nebopwsh foo.ps1pwsh fooScriptbez specifikace-File. Tato změna však vyžaduje, abyste explicitně zadali-cnebo-Commandpři pokusu o spuštění příkazů jakopwsh.exe -Command Get-Command. -
pwshpřijímá přepínač-i(nebo-Interactive), která označuje interaktivní prostředí. To umožňuje použití PowerShellu jako výchozího prostředí na platformách Unix. - Odstraněny parametry
-ImportSystemModulesa-PSConsoleFilezpwsh.exe. - Změněná
pwsh -Versiona vestavěná pomoc propwsh.exesladění s dalšími nativními nástroji. - Chybové zprávy neplatného argumentu pro
-Filea-Commanda ukončovací kódy konzistentní se standardy Unixu - Přidán
-WindowStyleparametr ve Windows. Podobně jsou aktualizace instalací založené na balíčcích na jiných platformách než Windows místní aktualizace.
Zkrácený název je také konzistentní s pojmenováním prostředí na platformách jiných než Windows.
Podpora spouštění skriptu PowerShellu s booleovským parametrem
Předtím neexistoval způsob, jak pomocí pwsh.exe spustit skript PowerShell a použít -File pro předání $true/$false jako hodnot parametrů. Byla přidána podpora $true/$false hodnot jako parsovaných parametrů. Podporují se také hodnoty přepínače.
Zlepšená zpětná kompatibilita s Windows PowerShell
Pro Windows je přidán nový parametr switche UseWindowsPowerShell do Import-Module. Tento switch vytváří proxy modul v PowerShell 7, který používá lokální proces Windows PowerShell k implicitnímu spuštění jakýchkoli cmdletů obsažených v tomto modulu. Další informace najdete v tématu Import-Module .
Pro více informací o tom, které moduly Microsoftu pracují s PowerShell 7.0, viz tabulka kompatibility modulů.
Podpora Microsoft Update pro Windows
PowerShell 7.2 přidal podporu pro Microsoft Update. Když tuto funkci povolíte, získáte nejnovější aktualizace PowerShell 7 ve vašem tradičním toku správy Windows Update (WU), ať už jde o Windows Update for Business, WSUS, SCCM nebo interaktivní dialog WU v Nastavení.
Balíček PowerShell 7.2 MSI obsahuje následující možnosti příkazové řádky:
-
USE_MU– Tato vlastnost má dvě možné hodnoty:-
1(výchozí) - Přihlásí se k aktualizaci přes Microsoft Update nebo WSUS -
0– Nepřihlašujte se k aktualizaci prostřednictvím služby Microsoft Update nebo WSUS.
-
ENABLE_MU-
1(výchozí) - Přihlásí se k použití Microsoft Update automatických aktualizací nebo Windows Update -
0- Nepřihlašujte se k používání automatických aktualizací služby Microsoft Update nebo služby Windows Update
-
Změny stroje
Podpora PowerShellu jako výchozího prostředí Unix
V unixu je to konvence pro prostředí, které přijímají -i pro interaktivní prostředí a mnoho nástrojů toto chování očekává (script například a při nastavování PowerShellu jako výchozího prostředí) a volá prostředí s přepínačem -i . Tato změna narušuje skutečnost, že -i dříve mohla být použita jako zkratka pro srovnávání -InputFormat, což nyní musí být -in.
Vlastní moduly snap-in
Moduly snap-in PowerShellu jsou předchůdcem modulů PowerShellu, které nemají v komunitě PowerShellu rozšířené přijetí.
Vzhledem ke složitosti podpory modulů snap-in a jejich nedostatečného využití v komunitě už nepodporujeme vlastní moduly snap-in v PowerShellu.
Příznaky experimentálních funkcí
Podpora experimentálních funkcí v PowerShellu 6.2 Vývojáři PowerShellu tak můžou doručovat nové funkce a získat zpětnou vazbu před dokončením návrhu. Tímto způsobem se vyhneme zásadním změnám při vývoji návrhu.
Použijte Get-ExperimentalFeature pro získání seznamu dostupných experimentálních funkcí. Tyto funkce můžete povolit nebo vypnout pomocí Enable-ExperimentalFeature a Disable-ExperimentalFeature.
Načtení sestavení ze základní cesty modulu před pokusem o načtení z GAC
Dříve, když měl binární modul sestavení v GAC, načítali jsme toto sestavení z GAC před tím, než jsme se ho pokusili načíst ze základní cesty modulu.
Přeskočit kontrolu prvku null u kolekcí s typem prvku value-type
Pro Mandatory parametry a ValidateNotNull a ValidateNotNullOrEmpty atributy přeskočte null-element kontrolu, zda je typ prvku kolekce typ hodnoty typu hodnoty.
Zachovat $? pro ParenExpression, SubExpression a ArrayExpression
Tento PR mění způsob, jakým kompilujeme dílčí pipeline (...), dílčí výrazy $(...) a pole výrazů @(), aby $? nebylo automaticky pravdivé. Místo toho hodnota $? závisí na výsledku spuštění kanálu nebo příkazů.
Oprava $?, aby nebyl $false, když nativní příkaz zapisuje do stderr.
$? není nastavena na $false při zápisu nativního příkazu do stderr. Nativní příkazy často zapisují do stderr bez úmyslu signalizovat selhání.
$? je nastaveno pouze na $false pokud má nativní příkaz nenulový ukončovací kód.
Zajistit, aby $ErrorActionPreference neovlivňoval výstup stderr nativních příkazů
Nativní příkazy běžně zapisují do stderr bez úmyslu indikovat selhání. S touto změnou stderr je výstup stále zachycen v objektech ErrorRecord , ale runtime již neplatí $ErrorActionPreference , pokud ErrorRecord pochází z nativního příkazu.
Změňte $OutputEncoding na použití UTF-8 NoBOM kódování místo ASCII.
Předchozí kódování ASCII (7bitová verze) by v některých případech vedlo k nesprávné změně výstupu. Nastavení UTF-8 NoBOM výchozího nastavení zachovává výstup Unicode s kódováním podporovaným většinou nástrojů a operačních systémů.
Upravte cmdlety s parametrem -Encoding tak, aby byly typu System.Text.Encoding
Hodnota -EncodingByte byla odebrána z cmdletů zprostředkovatele FileSystem. Nový parametr , se nyní používá k určení, -AsByteStreamzda je potřeba být jako vstup tok bajtů, nebo že výstup je proud bajtů.
Změňte kódování New-ModuleManifest na UTF8NoBOM na jiných platformách než Windows
New-ModuleManifest Dříve vytvořil psd1 manifesty v UTF-16 se znakem pořadí bajtů, což způsobilo problém pro linuxové nástroje. Tato zásadní změna mění kódování na New-ModuleManifest UTF (bez BOM) v ne-Windows platformách.
Odebrání AllScope z většiny výchozích aliasů
Aby se urychlilo vytváření rozsahu, AllScope bylo odstraněno z většiny výchozích aliasů.
AllScope zůstalo u několika často používaných aliasů, kde bylo vyhledávání rychlejší.
-Verbose a -Debug již nepřepisují $ErrorActionPreference
Dříve, pokud -Verbose-Debug byl nebo byl specifikován, přehlasoval chování .$ErrorActionPreference S touto změnou -Verbose a -Debug již neovlivňuje chování $ErrorActionPreference.
-Debug Dále se parametr nastaví na Continue místo na Inquire.
Zajistit, aby $PSCulture důsledně odrážely změny kulturního kontextu během relace.
Ve Windows PowerShell se aktuální hodnota nastavení kultury ukládá do mezipaměti, což může způsobit, že se hodnota po změně jazykového nastavení po spuštění relace nesynchronizuje. Toto chování při ukládání do mezipaměti je opravené v jádru PowerShellu.
Povolit explicitně zadaný pojmenovaný parametr nahradit stejný parametr z hashtable splatting
Při této změně se pojmenované parametry ze splattingu přesunou na konec seznamu parametrů, aby byly svázané po všech explicitně zadaných pojmenovaných parametrech. Vazby parametrů pro jednoduché funkce nevyvolají chybu, pokud zadaný pojmenovaný parametr nelze najít. Neznámé pojmenované parametry jsou vázány na $args parametr jednoduché funkce. Přesun splattingu na konec seznamu argumentů mění pořadí, v jakém se parametry objevují v $args.
Například:
function SimpleTest {
param(
$Name,
$Path
)
"Name: $Name; Path: $Path; Args: $args"
}
V předchozím chování není myPath vázán -Path , protože se jedná o třetí argument v seznamu argumentů. ## Takže to nakonec skončí nacpané do '$args' spolu s Blah = "World"
PS> $hash = @{ Name = "Hello"; Blah = "World" }
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: ; Args: -Blah: World MyPath
S touto změnou jsou argumenty z přesunuty @hash na konec seznamu argumentů.
MyPath se stane prvním argumentem v seznamu, takže je vázán na -Path.
PS> SimpleTest @hash "MyPath"
Name: Hello; Path: MyPath; Args: -Blah: World
Změny jazyka
Operátor nulového sjednocení ??
Operátor ?? nulového sjednocení vrátí hodnotu levého operandu, pokud není null.
V opačném případě vyhodnocuje pravý operand a vrátí výsledek. Operátor ?? nevyhodnocuje svůj pravý operand, pokud se levý operand vyhodnotí jako nenulový.
$x = $null
$x ?? 100
100
V následujícím příkladu nebude vyhodnocen pravý operand.
[string] $todaysDate = '1/10/2020'
$todaysDate ?? (Get-Date).ToShortDateString()
1/10/2020
Operátor přiřazení při sjednocení s hodnotou null ??=
Operátor přiřazení s nulovým sloučením ??= přiřadí hodnotu svého pravého operandu svému levému operandu pouze tehdy, pokud se levý operand vyhodnotí jako null. Operátor ??= nevyhodnocuje svůj pravý operand, pokud se levý operand vyhodnotí jako nenulový.
$x = $null
$x ??= 100
$x
100
V následujícím příkladu nebude vyhodnocen pravý operand.
[string] $todaysDate = '1/10/2020'
$todaysDate ??= (Get-Date).ToShortDateString()
1/10/2020
Podmíněné operátory s hodnotou Null
Poznámka:
Tato funkce byla přesunuta z experimentálního do hlavního proudu v PowerShellu 7.1.
Podmíněný operátor s hodnotou null aplikuje na svůj operand operaci přístup člena nebo ?.elementu ?[]pouze v případě, že se tento operand vyhodnotí jako nenulový. V opačném případě vrátí hodnotu null.
Vzhledem k tomu, že PowerShell umožňuje ? být součástí názvu proměnné, je pro použití těchto operátorů vyžadována formální specifikace názvu proměnné. Takže je nutné používat {} kolem názvů proměnných, například ${a} když ? je součástí názvu ${a?}proměnné.
V následujícím příkladu se vrátí hodnota PropName .
$a = @{ PropName = 100 }
${a}?.PropName
100
Následující příklad vrátí hodnotu null bez pokusu o přístup k názvu člena PropName.
$a = $null
${a}?.PropName
Podobně bude vrácena hodnota prvku.
$a = 1..10
${a}?[0]
1
A když je operand null, prvek není přístupný a vrátí se hodnota null.
$a = $null
${a}?[0]
Poznámka:
Syntaxe názvu proměnné by neměla být zaměňována s operátorem dílčího ${<name>} výrazu $() . Další informace naleznete v části Název proměnné about_Variables.
Přidání & operátoru pro řízení úloh
Umístění & na konec pipeline způsobí, že pipeline běží jako PowerShell úloha. Když je kanál na pozadí, vrátí se objekt úlohy. Jakmile pipeline běží jako úloha, lze použít všechny standardní *-Job cmdlety ke správě této úlohy. Proměnné (bez ohledu na procesově specifické proměnné) používané v pipeline se automaticky kopírují do úlohy, takže Copy-Item $foo $bar & to prostě funguje. Úloha se také spustí v aktuálním adresáři místo domovského adresáře uživatele.
Nové metody/vlastnosti na PSCustomObject
Přidali jsme nové metody a vlastnosti do PSCustomObject.
PSCustomObject nyní zahrnuje vlastnost Count/Length jako jiné objekty.
$PSCustomObject = [pscustomobject]@{foo = 1}
$PSCustomObject.Length
1
$PSCustomObject.Count
1
Tato práce také zahrnuje ForEach metody Where , které vám umožní pracovat a filtrovat PSCustomObject položky:
$PSCustomObject.ForEach({$_.foo + 1})
2
$PSCustomObject.Where({$_.foo -gt 0})
foo
---
1
Převody z PSMethod na delegáta
Můžete převést PSMethod na delegáta. To vám umožní například předat PSMethod[M]::DoubleStrLen hodnotu delegáta do [M]::AggregateString:
class M {
static [int] DoubleStrLen([string] $value) { return 2 * $value.Length }
static [long] AggregateString([string[]] $values, [Func[string, int]] $selector) {
[long] $res = 0
foreach($s in $values){
$res += $selector.Invoke($s)
}
return $res
}
}
[M]::AggregateString((gci).Name, [M]::DoubleStrLen)
Chování porovnání řetězců se změnilo v PowerShellu 7.1
PowerShell 7.1 je postaven na .NET 5.0, který přinesl následující zásadní změnu:
Od .NET 5.0 porovnání řetězců invariantní kulturou ignorují řídicí znaky, které nejsou tisknuté.
Například následující dva řetězce jsou považovány za totožné:
# Escape sequence "`a" is Ctrl-G or [char]7
'Food' -eq "Foo`ad"
True
Nové rutiny
Nový Get-Uptime cmdlet
Rutina Get-Uptime vrátí čas uplynulý od posledního spuštění operačního systému. Cmdlet byl představen v PowerShellu 6.0.
Nový Remove-Alias cmdlet
Rutina Remove-Alias odebere alias z aktuální relace PowerShellu. Cmdlet byl zaveden v PowerShellu 6.0.
Nový Remove-Service cmdlet
Rutina Remove-Service odebere službu systému Windows v registru a v databázi služby. Cmdlet Remove-Service byl představen v PowerShellu 6.0.
Nové rutiny Markdownu
Markdown je standard pro vytváření čitelných dokumentů ve formátu prostého textu se základním formátováním, které lze vykreslit do HTML.
V PowerShellu 6.1 byly přidány následující rutiny:
- ConvertFrom-Markdown – Převeďte obsah řetězce nebo souboru na objekt MarkdownInfo .
- Get-MarkdownOption – vrátí aktuální barvy a styly použité k vykreslení obsahu Markdownu v konzole.
- Set-MarkdownOption – Nastaví barvy a styly používané k vykreslení obsahu Markdownu v konzole.
- Show-Markdown – zobrazí obsah Markdownu v konzole nebo jako HTML.
Nový Test-Json cmdlet
Rutina Test-Json testuje, jestli je řetězec platným dokumentem JSON (JavaScript Object Notation) a může volitelně ověřit, že dokument JSON je v zadaném schématu.
Tato rutina byla představena v PowerShellu 6.1.
Nové rutiny pro podporu experimentálních funkcí
V PowerShellu 6.2 byly přidány následující rutiny pro podporu experimentálních funkcí.
- zakázat-ExperimentálníFunkce
- Povolit-ExperimentálníFunkci
- Get-ExperimentalFeature
Nový Join-String cmdlet
Rutina Join-String kombinuje objekty z kanálu do jednoho řetězce. Tento cmdlet byl přidán v PowerShellu 6.2.
Nové zobrazení ConciseView a cmdlet Get-Error
PowerShell 7.0 vylepšuje zobrazení chybových zpráv, aby se zlepšila čitelnost interaktivních chyb a chyb skriptů pomocí nového výchozího zobrazení ConciseView. Pohledy jsou uživatelsky vybírovatelné pomocí preferencní proměnné $ErrorView.
S ConciseView, pokud chyba není způsobena chybou skriptu nebo parseru, je to jednořádková chybová zpráva:
Get-ChildItem -Path C:\NotReal
Get-ChildItem: Can't find path 'C:\NotReal' because it doesn't exist
Pokud k chybě dojde při provádění skriptu nebo je to chyba analýzy, PowerShell vrátí víceřádkovou chybovou zprávu, která obsahuje chybu, ukazatel a chybovou zprávu s informacemi o tom, kde se chyba nachází na tomto řádku. Pokud terminál nepodporuje ANSI barevné únikové sekvence (VT100), barvy se nezobrazují.
Výchozí zobrazení v PowerShell 7 je ConciseView. Předchozí výchozí zobrazení bylo NormalView a můžete ho zvolit nastavením preference proměnné $ErrorView.
$ErrorView = 'NormalView' # Sets the error view to NormalView
$ErrorView = 'ConciseView' # Sets the error view to ConciseView
Poznámka:
Je přidána nová vlastnost $Host.PrivateData, která podporuje změnu barvy akcentu chybové zprávy.
Nový Get-Errorcmdlet poskytuje úplné podrobné zobrazení plně kvalifikované chyby dle potřeby. Ve výchozím nastavení cmdlet zobrazuje všechny detaily, včetně vnitřních výjimek, poslední chyby, která nastala.
Cmdlet Get-Error podporuje vstup z pipeline pomocí vestavěné proměnné $Error.
Get-Error zobrazuje všechny chyby v potrubí.
$Error | Get-Error
Cmdlet Get-Error podporuje parametr Nejnovější , což vám umožňuje určit, kolik chyb z aktuální relace chcete, aby se zobrazovalo.
Get-Error -Newest 3 # Displays the lst three errors that occurred in the session
Další informace naleznete v tématu Get-Error.
Změny rutin
Bylo přidáno paralelní spuštění do ForEach-Object
Počínaje PowerShellem 7.0 má rutina ForEach-Object, která iteruje položky v kolekci, nyní integrované paralelní zpracování s novým parametrem Parallel.
Ve výchozím nastavení paralelní skriptové bloky používají aktuální pracovní adresář volajícího, který paralelní úkoly zahájil.
Tento příklad získává 50 000 záznamů z 5 systémových logů na lokálním počítači Windows:
$logNames = 'Security','Application','System','Windows PowerShell','Microsoft-Windows-Store/Operational'
$logEntries = $logNames | ForEach-Object -Parallel {
Get-WinEvent -LogName $_ -MaxEvents 10000
} -ThrottleLimit 5
$logEntries.Count
50000
Parametr Parallel specifikuje blok skriptu, který běží paralelně pro každý název vstupního logu.
Nový parametr ThrottleLimit omezuje počet bloků skriptů běžících paralelně v daném okamžiku. Výchozí hodnota je 5.
Použijte proměnnou $_ k reprezentaci aktuálního vstupního objektu ve skriptním bloku. Pomocí modifikátoru Using: oboru můžete předat odkazy na proměnné do bloku spuštěného skriptu.
Další informace naleznete v tématu ForEach-Object.
Zkontrolujte system32 kompatibilní vestavěné moduly ve Windows
V aktualizaci Windows 10 1809 a Windows Serveru 2019 jsme aktualizovali řadu integrovaných modulů PowerShellu, abychom je označili jako kompatibilní s PowerShellem.
Při spuštění $windir\System32 PowerShellu se automaticky zahrne jako součást proměnné prostředí PSModulePath. Moduly však vystavuje pouze a Get-ModuleImport-Module pokud je označen CompatiblePSEdition jako kompatibilní s .Core
Toto chování můžete přepsat a zobrazit všechny moduly pomocí parametru -SkipEditionCheck switch.
Do výstupu tabulky jsme také přidali vlastnost PSEdition .
-lp alias pro všechny -LiteralPath parametry
Vytvořili jsme standardní alias -lp parametru pro všechny integrované rutiny PowerShellu -LiteralPath , které mají parametr.
Opravte Get-Item -LiteralPath a*b, pokud a*b ve skutečnosti neexistuje, aby vrátila chybu.
Dříve, pokud byla žolíková karta, -LiteralPath zacházela s ní stejně -Path jako a pokud nenašla žádné soubory, tiše odešla. Správné chování by mělo být, že je to -LiteralPath doslovné, takže pokud soubor neexistuje, měl by se objevit chybový signál. Změna je brát žolíky používané s s doslovně -Literal .
Nastavení pracovního adresáře na aktuální adresář v adresáři Start-Job
Cmdlet Start-Job teď používá aktuální adresář jako pracovní adresář pro nový úkol.
Odebrat -Protocol z *-Computer cmdletů
Parametr -Protocol byl odebrán z následujících rutin:
Rename-ComputerRestart-ComputerStop-Computer
DCOM se už nepodporuje pro vzdálené komunikace. Tyto rutiny podporují pouze vzdálené spojení WSMAN.
Odebrání -ComputerName z *-Service příkazů
Aby se podpořilo konzistentní používání PSRP, byl tento -ComputerName parametr odstraněn z *-Service cmdletů. Použijte Invoke-Command ke spuštění příkazových rutin na vzdálených počítačích.
Oprava Get-Content -Delimiter tak, aby neobsahoval oddělovač ve vrácených řádcích
Dříve byl výstup při používání Get-Content -Delimiter nekonzistentní a nepohodlný, protože bylo potřeba dalšího zpracování dat k odstranění oddělovače. Tato změna odebere oddělovač ve vrácených řádcích.
Změny v Format-Hex
Parametr -Raw teď nic nedělá. Cmdlet Format-Hex zobrazí skutečnou reprezentaci čísel, která zahrnuje všechny bajty daného typu. Toto je to, co -Raw parametr provedl před touto změnou.
Oprava překlepu v Get-ComputerInfo názvu vlastnosti
BiosSerialNumber bylo chybně napsáno a BiosSeralNumber bylo změněno na správný pravopis.
Změny dostupných hashovacích algoritmů
Z .NET byly odebrány následující hashovací algoritmy:
MACTripleDESRIPEMD160
Tato změna má vliv na příkaz Get-FileHash.
Přidání ověřování do Get-* rutin, kde předávání $null vrací všechny objekty místo chyby
Přihrávka $null na kterékoli z následujících nyní vyvolá chybu:
Get-Credential -UserNameGet-Event -SourceIdentifierGet-EventSubscriber -SourceIdentifierGet-Help -NameGet-PSBreakpoint -ScriptGet-PSProvider -PSProviderGet-PSSessionConfiguration -NameGet-Runspace -NameGet-RunspaceDebug -RunspaceNameGet-Service -NameGet-TraceSource -NameGet-Variable -Name
Přidejte podporu pro formát rozšířeného souboru protokolu W3C v Import-Csv
Dříve se Import-Csv rutina nemohla použít k přímému importu souborů protokolu v rozšířeném formátu protokolu W3C a byla vyžadována další akce. Při této změně se podporuje formát rozšířeného protokolu W3C.
Import-Csv se použije pstypenames při importu, pokud jsou v souboru CSV k dispozici informace o typu.
Dříve se objekty exportované pomocí Export-Csv s TypeInformation importované pomocí ConvertFrom-Csv nezachovávaly informace o typu. Tato změna přidává informace o typu člena pstypenames , pokud je dostupný ze souboru CSV.
-NoTypeInformation je ve výchozím nastavení na Export-Csv
Dříve rutina Export-Csv vypisovala komentář jako první řádek, který obsahoval název typu objektu. Tato změna standardně vylučuje informace o typu, protože jim většina nástrojů CSV nerozumí. Tato změna byla provedena, aby se vyřešila zpětná vazba zákazníků.
Použijte -IncludeTypeInformation k zachování předchozího chování.
Povolit použití * v cestě registru pro Remove-Item
Dříve, pokud byla žolíková karta, -LiteralPath zacházela s ní stejně -Path jako a pokud nenašla žádné soubory, tiše odešla. Správné chování by mělo být, že je to -LiteralPath doslovné, takže pokud soubor neexistuje, měl by se objevit chybový signál. Změna je brát žolíky používané s s doslovně -Literal .
Group-Object teď seřadí skupiny.
V rámci zlepšení výkonu nyní vrací Group-Object seřazený seznam skupin.
I když byste neměli spoléhat na pořadí, tato změna by vás mohla zasáhnout, pokud byste chtěli první skupinu. Rozhodli jsme se, že toto zlepšení výkonu stojí za změnu, protože dopad, který je závislý na předchozím chování, je nízký.
Směrodatná odchylka v Measure-Object
Výstup z Measure-Object nyní nově obsahuje vlastnost StandardDeviation.
Get-Process | Measure-Object -Property CPU -AllStats
Count : 308
Average : 31.3720576298701
Sum : 9662.59375
Maximum : 4416.046875
Minimum :
StandardDeviation : 264.389544720926
Property : CPU
Get-PfxCertificate -Password
Get-PfxCertificate nyní má parametr Password, který přebírá SecureString. To vám umožní používat neinteraktivně:
$certFile = '\\server\share\pwd-protected.pfx'
$certPass = Read-Host -AsSecureString -Prompt 'Enter the password for certificate: '
$certThumbPrint = (Get-PfxCertificate -FilePath $certFile -Password $certPass ).ThumbPrint
Odstranění more funkce
V minulosti PowerShell dodával na Windows more funkci nazvanou that wrapped more.com. Tato funkce byla nyní odebrána.
Funkce se také help změnila na použití more.com ve Windows nebo na výchozí stránkovač systému, který je specifikován na $Env:PAGER platformách mimo Windows.
cd DriveName: Nyní se uživatelé vrátí do aktuálního pracovního adresáře na tomto disku
Dříve použití Set-Location nebo cd návrat na PSDrive posílal uživatele na výchozí místo pro daný disk. Uživatelé jsou nyní přesměrováni do posledního pracovního adresáře v rámci relace.
cd - návraty do předchozího adresáře
C:\Windows\System32> cd C:\
C:\> cd -
C:\Windows\System32>
Nebo v Linuxu:
PS /etc> cd /usr/bin
PS /usr/bin> cd -
PS /etc>
Také a cd změňte cd -- na $HOME.
Update-Help Jako ne-administrátor
Na základě žádosti Update-Help veřejnosti už nemusí být provozován jako administrátor.
Update-Help Nyní se Nápověda ukládá do složky zaměřené uživatelem.
Where-Object -Not
Přidáním parametru -Not do Where-Object lze v potrubí filtrovat objekt podle neexistující vlastnosti nebo vlastnosti s hodnotou null či prázdnou.
Tento příkaz například vrátí všechny služby, které nemají definované žádné závislé služby:
Get-Service | Where-Object -Not DependentServices
Změny webových rutin
Základní .NET API webových cmdletů bylo změněno na System.Net.Http.HttpClient. Tato změna přináší mnoho výhod. Tato změna spolu s nedostatkem interoperability s Internet Explorerem však vedla k několika zásadním změnám uvnitř Invoke-WebRequest a Invoke-RestMethod.
-
Invoke-WebRequestnyní podporuje pouze základní HTML parsování.Invoke-WebRequestvždy vrátíBasicHtmlWebResponseObjectobjekt. AParsedHtmlnemovitosti bylyFormsodstraněny. -
BasicHtmlWebResponseObject.Headershodnoty jsou nyníString[]místo .String -
BasicHtmlWebResponseObject.BaseResponseje nyníSystem.Net.Http.HttpResponseMessageobjektem. - Vlastnost
Responsena výjimkách Web Cmdlet je nyníSystem.Net.Http.HttpResponseMessageobjekt. - Přísné parsování RFC hlaviček je nyní výchozím nastavením pro
-Headersparametr and-UserAgent(a parametr). To lze obejít pomocí-SkipHeaderValidation. -
file://a schémata URI již nejsou podporovánaftp://. -
System.Net.ServicePointManagerNastavení již nejsou ctěna. - V systému macOS aktuálně není k dispozici ověřování založené na certifikátech.
- Použití nad
-Credentialhttp://URI povede k chybě. Použijtehttps://URI nebo zadejte-AllowUnencryptedAuthenticationparametr k potlačení chyby. -
-MaximumRedirectionnyní vzniká chyba při pokusech o přesměrování překročí daný limit místo toho, aby se vrátily výsledky posledního přesměrování. - V PowerShellu 6.2 došlo ke změně ve výchozím nastavení kódování UTF-8 pro odpovědi JSON. Pokud pro odpověď JSON není zadána znaková sada, mělo by být výchozí kódování UTF-8 na RFC 8259.
- Výchozí kódování nastavené na UTF-8 pro
application-jsonodpovědi - Přidání
-SkipHeaderValidationparametru pro povoleníContent-Typehlaviček, které nedodržují standardy - Přidání
-Formparametru pro podporu zjednodušenémultipart/form-datapodpory - Souladné zpracování relačních klíčů bez rozlišování velkých a malých písmen
- Přidán parametr
-Resumepro webové cmdlety
Invoke-RestMethod vrátí užitečné informace, pokud se nevrátí žádná data.
Když rozhraní API vrátí pouze null, Invoke-RestMethod to serializovalo jako řetězec "null" místo $null. Tato změna fixuje logiku v pro Invoke-RestMethod správnou serializaci platného jednohodnotového JSON null literálu jako .$null
Webové cmdlety varují, když je -Credential odesílán přes nešifrovaná připojení
Při použití protokolu HTTP se obsah včetně hesel odešle jako prostý text. Tato změna ve výchozím nastavení toto nepovolí a vrátí chybu, pokud se přihlašovací údaje předávají nezabezpečeným způsobem. Uživatelé to mohou obejít pomocí spínače -AllowUnencryptedAuthentication .
Nastavení -OutFile parametru ve webových rutinách tak, aby fungoval jako -LiteralPath
Počínaje PowerShell 7.1 funguje parametr OutFile u webových cmdletů jako LiteralPath a nezpracovává zástupné znaky.
Změny rozhraní API
Odebrat AddTypeCommandBase třídu
Třída AddTypeCommandBase byla odstraněna kvůli Add-Type zlepšení výkonu. Třídu Add-Type používá pouze cmdlet a neměla by mít vliv na uživatele.
Odstraněno VisualBasic jako podporovaný jazyk v Add-Type
V minulosti jste mohli kód ve Visual Basicu kompilovat pomocí Add-Type cmdletu. Visual Basic byl s . Add-Typepoužíván jen zřídka. Tuto funkci jsme odebrali, abychom zmenšili velikost PowerShellu.
RunspaceConfiguration Podpora byla odebrána
Dříve jste při programovém vytváření prostředí Runspace PowerShellu pomocí rozhraní API mohli použít starší RunspaceConfiguration nebo novější InitialSessionState třídy. Tato změna odstranila podporu a RunspaceConfiguration pouze podporu InitialSessionState.
CommandInvocationIntrinsics.InvokeScriptsvázat argumenty s $input místo $args
Nesprávná pozice parametru způsobila, že argumenty předané jako vstup místo jako argy.
Odeberte vlastnosti ClrVersion a BuildVersion z $PSVersionTable
Vlastnost ClrVersion$PSVersionTable není užitečná s CoreCLR. Koncoví uživatelé by k určení kompatibility neměli používat danou hodnotu.
Vlastnost BuildVersion byla svázaná s verzí buildu Windows, která není k dispozici na platformách jiných než Windows. Použijte vlastnost GitCommitId pro získání přesné verze sestavení PowerShellu.
Implementace parsování Unicode escape sekvencí
`u#### nebo `u{####} je převedeno na odpovídající znak Unicode. Pro výstup literálu `uunikněte zpětnému ticku: ``u.
Problém s vazbou parametrů ve ValueFromRemainingArguments funkcích PS
ValueFromRemainingArguments nyní vrací hodnoty jako pole místo jedné hodnoty, která je sama pole.
Vyčištěné využití CommandTypes.Workflow a WorkflowInfoCleaned
Vyčistěte kód související s používáním CommandTypes.Workflow a WorkflowInfo v system.Management.Automation.
Tyto menší zásadní změny mají vliv hlavně na kód zprostředkovatele nápovědy.
- Změňte veřejné konstruktory
WorkflowInfona interní. Pracovní postup už nepodporujeme, takže je vhodné nepovolit uživatelům vytvářetWorkflowinstance. - Odeberte typ System.Management.Automation.DebugSource , protože se používá jenom pro ladění pracovního postupu.
- Odeberte přetížení
SetParentz abstraktní třídy Debugger, která se používá pouze pro ladění pracovního postupu. - Odeberte stejné přetížení
SetParentz odvozené třídy RemotingJobDebugger.
Neobalovat výsledek vrácení PSObject když se ScriptBlock převádí na delegáta
Když je a ScriptBlock převedeno na typ delegáta pro použití v kontextu C#, zabalení výsledku do a PSObject přináší zbytečné potíže:
- Když je hodnota převedena na typ vrácení delegáta, v podstatě se rozbalí
PSObject. Takže toPSObjectnení potřeba. - Když je typ návratu delegáta ,
objectje zabalený do aPSObjectcož ztěžuje práci v kódu C#.
Po této změně je vrácený objekt základním objektem.
Podpora vzdáleného připojení
Vzdálená správa PowerShellu (PSRP) s využitím WinRM není podporována pro platformy mimo Windows. Pomocí vzdáleného prostředí PowerShellu (PSRP) přes WinRM z Windows se můžete připojit k jiným počítačům s Windows. PowerShell také podporuje vzdálené komunikace přes SSH na všech platformách (Windows, macOS a Linux). Další informace najdete v tématu Vzdálená správa SSH v PowerShellu.
PowerShell Direct for Containers se pokusí použít pwsh jako první
PowerShell Direct je funkce PowerShellu a Hyper-V, která vám umožňuje připojit se k Hyper-V VM nebo kontejneru bez síťového připojení nebo jiných vzdálených správcovských služeb.
PowerShell Direct se v minulosti připojil pomocí integrované instance Windows PowerShellu v kontejneru. PowerShell Direct se nejprve pokusí připojit pomocí jakékoli dostupné pwsh.exe proměnné PATH prostředí. Pokud pwsh.exe není dostupný, PowerShell Direct se vrací k použití powershell.exe.
Enable-PSRemoting Nyní vytváří samostatné vzdálené endpointy pro preview verze
Enable-PSRemoting Nyní vytváří dvě konfigurace vzdálených relací:
- Jedna pro hlavní verzi PowerShellu. Například:
PowerShell.6. Tento koncový bod, který se dá spoléhat na aktualizace podverze, jako konfiguraci relace PowerShellu 6 pro celý systém - Jedna verze specifická konfigurace relace, například:
PowerShell.6.1.0
Toto chování je užitečné, pokud chcete mít na stejném počítači nainstalovaných a přístupných více verzí PowerShellu 6.
Navíc náhledové verze PowerShellu nyní po spuštění Enable-PSRemoting cdletu dostávají vlastní konfigurace vzdálených relací:
C:\WINDOWS\system32> Enable-PSRemoting
Pokud jste ještě nenastavili WinRM, může se výstup lišit.
WinRM is already set up to receive requests on this computer.
WinRM is already set up for remote management on this computer.
Pak můžete zobrazit samostatné konfigurace relací PowerShellu pro verze Preview a stabilní sestavení PowerShellu 6 a pro každou konkrétní verzi.
Get-PSSessionConfiguration
Name : PowerShell.6.2-preview.1
PSVersion : 6.2
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
Name : PowerShell.6-preview
PSVersion : 6.2
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
Name : powershell.6
PSVersion : 6.1
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
Name : powershell.6.1.0
PSVersion : 6.1
StartupScript :
RunAsUser :
Permission : NT AUTHORITY\INTERACTIVE AccessAllowed, BUILTIN\Administrators AccessAllowed, BUILTIN\Remote Management Users AccessAllowed
user@host:port Syntax podporovaná pro SSH
SSH klienti obvykle podporují spojovací řetězec ve formátu user@host:port. S přidáním protokolu SSH jako protokolu pro vzdálené komunikace PowerShellu jsme přidali podporu pro tento formát připojovacího řetězce:
Enter-PSSession -HostName fooUser@ssh.contoso.com:2222
Telemetrie se dá zakázat jenom s proměnnou prostředí.
PowerShell odesílá do Microsoftu základní telemetrická data při spuštění. Data zahrnují název operačního systému, verzi operačního systému a verzi PowerShellu. Tato data nám umožňují lépe porozumět prostředím, kde se používá PowerShell, a umožňuje nám určit prioritu nových funkcí a oprav.
Pokud chcete tuto telemetrii zrušit, nastavte proměnnou prostředí POWERSHELL_TELEMETRY_OPTOUT na true, yesnebo 1. Již nepodporujeme smazání souboru DELETE_ME_TO_DISABLE_CONSOLEHOST_TELEMETRY pro deaktivaci telemetrie.