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äß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.
  • 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
  • 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 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äß. 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.