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. Weitere Änderungen wurden vorgenommen, um die Interoperabilität von PowerShell auf anderen Plattformen als Windows 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, eventuell 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äßig less.
• Der abschließende umgekehrte Schrägstrich wird bei nativen Befehlsargumenten automatisch mit einem Escapezeichen versehen.
• ConsoleHost berücksichtigt auf Unix-Plattformen jetzt NoEcho.
• Fügen Sie nicht die PATHEXT-Umgebungsvariable unter Unix hinzu.
• Eine powershell-Manpage ist im Paket enthalten.

Ausführungsrichtlinie

PowerShell ignoriert Ausführungsrichtlinien, wenn sie auf anderen Plattformen als Windows ausgeführt werden. 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 beachtet, und PowerShell hält sich an den Standard des Dateisystems.

• Sie müssen die korrekte Groß-/Kleinschreibung verwenden, wenn ein Dateiname in PowerShell angegeben wird.
• 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ägstrichunabhängig, 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
• Unterstützung für Datei- und Ordnernamen mit Doppelpunkt unter Unix.
• Unterstützung für Skriptnamen oder vollständige Pfade, die Kommas enthalten.
• Erkennen Sie, wenn der LiteralPath-Parameter verwendet wird, um die Wildcard-Erweiterung für Navigations-Cmdlets zu unterdrücken.
• Get-ChildItem wurde in der Funktionsweise an ls -R in *nix und native DIR /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äß. Dieses Verhalten kann beim Ausführen eines PowerShell-Skripts aus Bash oder einer anderen Shell wünschenswert sein.

Entfernung von einfach verwendbaren Aliases

Unter Windows stellt PowerShell einige Aliase bereit, die den Linux-Befehlsnamen zugeordnet sind und so 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 und ps entfernt, damit die native ausführbare Datei ohne die Angabe eines Pfads ausgeführt werden kann.

Logging

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 jedoch 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 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)

Mit PowerShell unter Linux oder macOS können Sie keine JEA-Remoting-Endpunkte (eingeschränkte Administrationsendpunkte) erstellen.

sudo, exec und PowerShell

Da PowerShell die meisten Befehle im Arbeitsspeicher ausführt wie Python oder Ruby, 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. sudo Set-Date 8/18/2016, sollten Sie sudo pwsh Set-Date 8/18/2016 verwenden.

Module, die auf anderen Plattformen als Windows enthalten 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
• PSReadLine
• ThreadJob

Viele Befehle (Cmdlets), die normalerweise in PowerShell verfügbar sind, sind unter Linux oder macOS nicht verfügbar. Häufig gelten diese Befehle nicht für diese Plattformen. Befehle für Windows-spezifische Features wie die Registrierung oder Dienste sind z. B. nicht verfügbar. Andere Befehle wie Set-ExecutionPolicy sind vorhanden, aber nicht funktionsfähig.

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

Einige Cmdlets wurden aus PowerShell entfernt. Andere sind nicht verfügbar oder funktionieren möglicherweise auf anderen Plattformen als Windows anders. Eine umfassende Liste der aus PowerShell entfernten Cmdlets finden Sie unter Aus PowerShell entfernte Cmdlets.

Microsoft.PowerShell.Core

Die folgenden Cmdlets sind unter Linux oder macOS nicht verfügbar:

• Disable-PSRemoting
• Enable-PSRemoting
• Connect-PSSession
• Disconnect-PSSession
• Receive-PSSession
• Get-PSSessionCapability
• Disable-PSSessionConfiguration
• Enable-PSSessionConfiguration
• Get-PSSessionConfiguration
• Register-PSSessionConfiguration
• Set-PSSessionConfiguration
• Unregister-PSSessionConfiguration
• Test-PSSessionConfigurationFile

Der ShowWindow-Parameter von Get-Help ist für Nicht-Windows-Plattformen nicht verfügbar. Bei PowerShell 7.3 wurden das Cmdlet Switch-Process und die Funktion exec für Linux und macOS hinzugefügt. Diese Befehle sind unter Windows 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:

• Rename-Computer
• Get-ComputerInfo
• Get-HotFix
• Clear-RecycleBin
• Get-Service
• New-Service
• Remove-Service
• Restart-Service
• Resume-Service
• Set-Service
• Start-Service
• Stop-Service
• Suspend-Service
• Set-TimeZone

Die folgenden Cmdlets sind mit Einschränkungen verfügbar:

• Get-Clipboard: verfügbar in PowerShell 7.0 und höher
• Set-Clipboard: verfügbar in PowerShell 7.0 und höher
• Restart-Computer: verfügbar für Linux und macOS in PowerShell 7.1 und höher
• Stop-Computer: verfügbar für Linux und macOS in PowerShell 7.1 und höher

Microsoft.PowerShell.Utility-Cmdlets

Die folgenden Cmdlets sind unter Linux und macOS nicht verfügbar:

• Convert-String
• ConvertFrom-String
• ConvertFrom-SddlString
• 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 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
compare	Compare-Object
cp	Copy-Item
cpp	Copy-ItemProperty
diff	Compare-Object
kill	Stop-Process
ls	Get-ChildItem
man	help
mount	New-PSDrive
mv	Move-Item
ps	Get-Process
rm	Remove-Item
rmdir	Remove-Item
sleep	Start-Sleep
sort	Sort-Object
start	Start-Process
tee	Tee-Object
write	Write-Output

Die Tabelle enthält keine Aliase, die nicht für Cmdlets verfügbar sind, die nicht auf anderen Plattformen als Windows vorhanden sind.

PowerShell Desired State Configuration (DSC)

Ab 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. Weitere Informationen zur Verwendung von DSC unter Linux finden Sie unter Erste Schritte mit DSC für Linux. DSC v1.1 und v2.x werden unter macOS nicht unterstützt. DSC v3 wird unter Windows, Linux und macOS unterstützt, befindet aber noch in einer frühen Entwicklungsphase.