PowerShell-Unterschiede auf Nicht-Windows-Plattformen
PowerShell ist bestrebt, Featureparität für alle unterstützten Plattformen zu bieten. Aufgrund von Unterschieden in .NET Core und plattformspezifischen Unterschieden verhalten sich einige Features jedoch anders oder sind nicht verfügbar. Es wurden zusätzliche Änderungen vorgenommen, um die Interoperabilität von PowerShell auf Nicht-Windows-Plattformen zu verbessern.
.NET Framework und .NET Core
PowerShell unter Linux und macOS verwendet .NET Core. Dabei handelt es sich um eine Teilmenge des vollständigen .NET Frameworks unter Microsoft Windows. Folglich können Skripts, die unter Windows ausgeführt werden, nicht auf anderen Plattformen als Windows ausgeführt werden, da die Frameworks sich unterscheiden.
Weitere Informationen zu Änderungen in .NET Core finden Sie unter Breaking Changes für die Migration von .NET Framework zu .NET Core.
Allgemeine Unix-Interoperabilitätsänderungen
- Unterstützung der nativen Verwendung von Platzhaltern in Befehlen auf Unix-Plattformen Dies bedeutet, dass Sie Platzhalter mit nativen Befehlen wie
ls *.txt
verwenden können. - Die
more
-Funktionalität respektiert$PAGER
von Linux und entspricht standardmäßigless
. - Der abschließende umgekehrte Schrägstrich wird bei nativen Befehlsargumenten automatisch mit einem Escapezeichen versehen.
- ConsoleHost berücksichtigt auf Unix-Plattformen jetzt
NoEcho
. - Kein Hinzufügen der
PATHEXT
-Umgebungsvariablen unter Unix - Eine
powershell
-Manpage ist im Paket enthalten
Ausführungsrichtlinie
Der -ExecutionPolicy
-Parameter wird ignoriert, wenn PowerShell auf Nicht-Windows-Plattformen ausgeführt wird.
Get-ExecutionPolicy
gibt unter Linux und macOS Uneingeschränkt zurück. Set-ExecutionPolicy
funktioniert nicht unter Linux und macOS.
Groß-/Kleinschreibung in PowerShell
Bisher wurde die Groß- und Kleinschreibung in PowerShell mit wenigen Ausnahmen generell nicht berücksichtigt. Auf UNIX-ähnlichen Betriebssystemen wird im Dateisystem überwiegend die Groß-/Kleinschreibung unterschieden, und PowerShell hält sich an den Standard des Dateisystems.
- Wenn Sie eine Datei in PowerShell angeben, muss die korrekte Groß-/Kleinschreibung verwendet werden.
- Wenn ein Skript versucht, ein Modul zu laden, und die Groß- und Kleinschreibung des Moduls nicht korrekt ist, tritt beim Laden des Moduls ein Fehler auf. Dies kann zu Problemen mit vorhandenen Skripts führen, wenn der Name, mit dem auf das Modul verwiesen wird, nicht mit der korrekten Groß- und Kleinschreibung des tatsächlichen Dateinamens übereinstimmt.
- Während bei Namen im Dateisystem die Groß-/Kleinschreibung beachtet wird, ist die Vervollständigung von Dateinamen mit der TAB-Taste nicht von der Groß-/Kleinschreibung abhängig. Die Vervollständigung mit der TAB-Taste durchläuft die Liste der Namen ohne Beachtung der Groß-/Kleinschreibung.
Get-Help
unterstützt Mustervergleiche auf Unix-Plattformen, bei denen die Groß-/Kleinschreibung nicht beachtet wird.- Bei
Import-Module
wird die Groß-/Kleinschreibung nicht beachtet, wenn der Modulname mit einem Dateinamen bestimmt werden soll.
Dateisystemunterstützung für Linux und macOS
- Pfade, die an Cmdlets übergeben werden, sind jetzt schrägstrichagnostisch, d.h., dass sowohl „/“ als auch „\“ als Verzeichnistrennzeichen akzeptiert werden.
- Die XDG Base Directory-Spezifikation wird eingehalten und standardmäßig verwendet:
- Der Linux/macOS-Profilpfad lautet
~/.config/powershell/profile.ps1
- Der Speicherpfad für den Verlauf lautet
~/.local/share/powershell/PSReadline/ConsoleHost_history.txt
- Der Benutzermodulpfad lautet
~/.local/share/powershell/Modules
- Der Linux/macOS-Profilpfad lautet
- Unterstützung für Datei- und Ordnernamen mit Doppelpunkt unter Unix.
- Unterstützung für Skriptnamen oder vollständige Pfade, die Kommas enthalten.
- Es wird erkannt, wann mit
-LiteralPath
die Platzhaltererweiterung für Navigations-Cmdlets unterdrückt wird. Get-ChildItem
wurde in der Funktionsweise anls -R
in *nix und nativeDIR /S
-Windows-Befehle angeglichen.Get-ChildItem
gibt jetzt die symbolischen Links zurück, die bei einer rekursiven Suche gefunden wurden, und sucht nicht in den Verzeichnissen, zu denen die Links führen.
PS1-Dateierweiterungen
PowerShell-Skripts müssen auf .ps1
enden, damit der Interpreter weiß, wie diese im aktuellen Prozess geladen und ausgeführt werden müssen. Das Ausführen von Skripts im aktuellen Prozess wird als übliches Verhalten für PowerShell vorausgesetzt. Die magische Zahl #!
kann einem Skript ohne die Erweiterung .ps1
hinzugefügt werden, dadurch wird das Skript jedoch in einer neuen PowerShell-Instanz ausgeführt, und das Austauschen von Objekten funktioniert nicht ordnungsgemäß. Dabei kann es sich um das erwünschte Verhalten handeln, wenn ein PowerShell-Skript über bash
oder eine andere Shell ausgeführt wird.
Entfernung von einfach verwendbaren Aliases
Unter Windows stellt PowerShell einige Aliase bereit, die den Linux-Befehlsnamen zugeordnet sind und die Benutzerfreundlichkeit erhöhen. Unter Linux und macOS wurden die einfach verwendbaren Aliase für die grundlegenden Befehle ls
, cp
, mv
, rm
, cat
, man
, mount
, ps
entfernt, damit die native ausführbare Datei ohne die Angabe eines Pfads ausgeführt werden kann.
Protokollierung
Unter macOS verwendet PowerShell native os_log
-APIs zur Anmeldung beim einheitlichen Protokollierungssystem von Apple.
Unter Linux verwendet PowerShell Syslog, eine weit verbreitete Protokollierungslösung.
Auftragssteuerung
Es gibt keine Unterstützung für die Auftragssteuerung im Unix-Format in PowerShell unter Linux oder macOS. Die Befehle fg
und bg
sind nicht verfügbar. Sie können PowerShell-Aufträge verwenden, die auf allen Plattformen funktionieren.
Wenn Sie ein &
am Ende einer Pipeline einfügen, wird die Pipeline als PowerShell-Auftrag ausgeführt. In diesem Fall wird ein Auftragsobjekt zurückgegeben. Wird die Pipeline als Auftrag ausgeführt, kann sie mithilfe aller *-Job
-Cmdlets verwaltet werden. Die in der Pipeline verwendeten Variablen (außer der prozessspezifischen) werden automatisch in den Auftrag kopiert, sodass Copy-Item $foo $bar &
funktioniert. Der Auftrag wird auch im aktuellen Verzeichnis statt im Basisverzeichnis des Benutzers ausgeführt.
Unterstützung für das Remoting
PowerShell-Remoting (PSRP) mit WinRM auf Unix-Plattformen erfordert NTLM/Negotiate oder die Standardauthentifizierung über HTTPS. PSRP unter macOS unterstützt nur die Standardauthentifizierung über HTTPS. Die Kerberos-basierte Authentifizierung wird nicht unterstützt.
PowerShell unterstützt das PowerShell-Remoting (PSRP) auf allen Plattformen (Windows, macOS, Linux) über SSH. Weitere Informationen finden Sie unter SSH-Remoting in PowerShell.
Unterstützung für Just Enough Administration (JEA)
Es können keine eingeschränkten JEA-Remotingendpunkte in PowerShell unter Linux oder macOS erstellt werden.
sudo
, exec
und PowerShell
Da PowerShell (wie Python oder Ruby) die meisten Befehle im Arbeitsspeicher ausführt, können Sie sudo nicht direkt mit integrierten PowerShell-Features verwenden. Sie können pwsh
über sudo ausführen. Wenn es erforderlich ist, ein PowerShell-Cmdlet innerhalb von PowerShell mit sudo auszuführen, z. B. im Fall von sudo Set-Date 8/18/2016
, sollten Sie sudo pwsh Set-Date 8/18/2016
verwenden.
Fehlende Cmdlets
Viele Befehle (Cmdlets), die normalerweise in PowerShell verfügbar sind, sind unter Linux oder macOS nicht verfügbar. In vielen Fällen sind diese Befehle auf diesen Plattformen überflüssig, z.B. Befehle für Windows-spezifische Features wie die Registrierung. Andere Befehle wie die zur Steuerung von Diensten sind vorhanden, aber nicht funktionsfähig. Diese Probleme werden vielleicht in zukünftigen Releases behoben, indem die fehlerhaften Cmdlets korrigiert und neue hinzugefügt werden.
Eine umfassende Liste der Module und Cmdlets sowie der unterstützten Plattformen finden Sie unter Releaseverlauf von Modulen und Cmdlets.
Nicht mehr im Lieferumfang von PowerShell enthaltene Module
Aus verschiedenen Kompatibilitätsgründen sind die folgenden Module nicht mehr in PowerShell enthalten.
- ISE
- Microsoft.PowerShell.LocalAccounts
- Microsoft.PowerShell.ODataUtils
- Microsoft.PowerShell.Operation.Validation
- PSScheduledJob
- PSWorkflow
- PSWorkflowUtility
Die folgenden Windows-spezifischen Module sind in PowerShell für Linux oder macOS nicht enthalten.
- CimCmdlets
- Microsoft.PowerShell.Diagnostics
- Microsoft.WSMan.Management
- PSDiagnostics
Cmdlets, die auf Nicht-Windows-Plattformen nicht verfügbar sind
Für Nicht-Windows-Plattformen umfasst PowerShell die folgenden Module:
- Microsoft.PowerShell.Archive
- Microsoft.PowerShell.Core
- Microsoft.PowerShell.Host
- Microsoft.PowerShell.Management
- Microsoft.PowerShell.Security
- Microsoft.PowerShell.Utility
- PackageManagement
- PowerShellGet
- PSDesiredStateConfiguration
- PSReadLine
- ThreadJob
Einige Cmdlets wurden jedoch aus PowerShell entfernt, und andere sind nicht verfügbar oder verhalten sich auf Nicht-Windows-Plattformen möglicherweise anders. Eine umfassende Liste der aus PowerShell entfernten Cmdlets finden Sie unter Aus PowerShell entfernte Cmdlets.
Microsoft.PowerShell.Core
Der ShowWindow-Parameter von Get-Help
ist für Nicht-Windows-Plattformen nicht verfügbar.
Microsoft.PowerShell.Security-Cmdlets
Die folgenden Cmdlets sind unter Linux oder macOS nicht verfügbar:
Get-Acl
Set-Acl
Get-AuthenticodeSignature
Set-AuthenticodeSignature
New-FileCatalog
Test-FileCatalog
Diese Cmdlets sind erst ab PowerShell 7.1 verfügbar.
Get-CmsMessage
Protect-CmsMessage
Unprotect-CmsMessage
Microsoft.PowerShell.Management-Cmdlets
Die folgenden Cmdlets sind unter Linux und macOS nicht verfügbar:
Clear-RecycleBin
Get-HotFix
Die folgenden Cmdlets sind mit Einschränkungen verfügbar:
Get-Clipboard
– verfügbar unter Linux, aber unter macOS nicht unterstützt Set-Clipboard
– verfügbar in PowerShell 7.0+ Restart-Computer
– verfügbar für Linux und macOS in PowerShell 7.1+ Stop-Computer
– verfügbar für Linux und macOS in PowerShell 7.1+
Microsoft.PowerShell.Utility-Cmdlets
Die folgenden Cmdlets sind unter Linux und macOS nicht verfügbar:
Convert-String
ConvertFrom-String
Out-GridView
Out-Printer
Show-Command
Unter Linux oder macOS nicht verfügbar Aliase
In der folgenden Tabelle sind die für Windows verfügbaren Aliase aufgeführt, die auf Nicht-Windows-Plattformen nicht verfügbar sind. Diese Aliase sind nicht verfügbar, da das Ziel-Cmdlet nicht verfügbar ist oder der Alias zu Konflikten mit einem nativen Befehl auf diesen Plattformen führen würde.
Alias | Cmdlet |
---|---|
ac |
Add-Content |
cat |
Get-Content |
clear |
Clear-Host |
cnsn |
Connect-PSSession |
compare |
Compare-Object |
cp |
Copy-Item |
cpp |
Copy-ItemProperty |
diff |
Compare-Object |
dnsn |
Disconnect-PSSession |
gsv |
Get-Service |
kill |
Stop-Process |
ls |
Get-ChildItem |
man |
help |
mount |
New-PSDrive |
mv |
Move-Item |
ogv |
Out-GridView |
ps |
Get-Process |
rm |
Remove-Item |
rmdir |
Remove-Item |
sasv |
Start-Service |
shcm |
Show-Command |
sleep |
Start-Sleep |
sort |
Sort-Object |
spsv |
Stop-Service |
start |
Start-Process |
tee |
Tee-Object |
write |
Write-Output |
PowerShell Desired State Configuration (DSC)
Ab PowerShell 6.0 wurden viele Cmdlets aus dem PSDesiredStateConfiguration-Modul entfernt.
Die Unterstützung für DSC auf Nicht-Windows-Plattformen ist eingeschränkt und größtenteils experimentell. Das Cmdlet Invoke-DscResource
wurde als experimentelles Feature in PowerShell 7.0 wiederhergestellt.
DSC wird unter macOS nicht unterstützt.
Weitere Informationen zur Verwendung von DSC unter Linux finden Sie unter Erste Schritte mit DSC für Linux.
Beginnend mit PowerShell 7.2 wurde das PSDesiredStateConfiguration-Modul aus PowerShell entfernt und im PowerShell-Katalog veröffentlicht. Weitere Informationen finden Sie im PowerShell-Teamblog in der Ankündigung.
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter:Feedback senden und anzeigen für