Différences de PowerShell sur les plateformes non-Windows

PowerShell s’efforce de fournir une parité des fonctionnalités sur toutes les plateformes prises en charge. Toutefois, certaines fonctionnalités se comportent de manière distincte ou ne sont pas disponibles en raison des différences de .NET Core et des différences spécifiques à chaque plateforme. D’autres modifications ont été apportées pour améliorer l’interopérabilité de PowerShell sur les plateformes non-Windows.

Comparaison entre le .NET Framework et .NET Core

PowerShell sur Linux et macOS utilise .NET Core, un sous-ensemble de la version complète de .NET Framework sur Microsoft Windows. Par conséquent, les scripts qui s’exécutent sous Windows pourraient ne pas fonctionner sur les plateformes non-Windows en raison des différences d’infrastructure.

Pour plus d’informations sur les changements de .NET Core, consultez Changements cassants pour la migration du .NET Framework vers .NET Core.

Changements généraux de l’interopérabilité sur UNIX

• Ajout de la prise en charge du globbing des commandes natives sur les plateformes Unix. Cela signifie que vous pouvez utiliser des caractères génériques avec des commandes natives comme ls *.txt.
• La fonctionnalité more respecte l’élément $PAGER Linux et a comme valeur par défaut less.
• La barre oblique inverse de fin est automatiquement placée dans une séquence d’échappement quand vous traitez des arguments de commande native.
• Correction de ConsoleHost pour honorer NoEcho sur les plateformes Unix.
• N’ajoutez pas la variable d’environnement PATHEXT sur Unix.
• Une page man powershell est comprise dans le package.

Stratégie d’exécution

PowerShell ignore les stratégies d’exécution lors de l’exécution sur des plateformes non-Windows. Get-ExecutionPolicy retourne Unrestricted sur Linux et macOS. Set-ExecutionPolicy ne fait rien sur Linux et macOS.

Respect de la casse dans PowerShell

Historiquement, PowerShell ne respecte jamais la casse, à quelques exceptions près. Sur les systèmes d’exploitation de type UNIX, le système de fichiers respecte majoritairement la casse et PowerShell est conforme au standard du système de fichiers.

• Vous devez utiliser la casse correcte lorsqu’un nom de fichier est spécifié dans PowerShell.
• Si un script tente de charger un module dont le nom n’a pas la bonne casse, le chargement du module échoue. Ce comportement peut engendrer un problème avec les scripts existants si le nom référencé par le module ne correspond pas à la casse appropriée du nom de fichier réel.
• Bien que les noms utilisés dans le système de fichiers respectent la casse, la complétion des noms de fichiers par tabulation ne respecte pas la casse. La saisie semi-automatique par tabulation parcourt la liste des noms sans faire attention à la casse.
• Get-Help prend en charge les critères spéciaux ne respectant par la casse sur les plateformes UNIX.
• Import-Module ne respecte pas la casse lorsqu’il est utilisé avec un nom de fichier pour déterminer le nom du module.

Prise en charge du système de fichiers pour Linux et macOS

• Les chemins associés aux cmdlets sont désormais indépendants des barres obliques (/ et \ fonctionnent tous deux comme séparateur de répertoires)
• La spécification de répertoire de base XDG est maintenant respectée et utilisée par défaut :
  • Le chemin du profil Linux/macOS se trouve dans ~/.config/powershell/profile.ps1
  • Le chemin d’enregistrement de l’historique se trouve dans ~/.local/share/powershell/PSReadline/ConsoleHost_history.txt
  • Le chemin du module utilisateur se trouve dans ~/.local/share/powershell/Modules
• Prise en charge des noms de fichier et de dossier qui contiennent le caractère deux-points sous Unix.
• Prise en charge des noms de script ou des chemins complets qui contiennent des virgules.
• Détectez quand le paramètre LiteralPath est utilisé pour supprimer l’extension générique pour les cmdlets de navigation.
• Mise à jour de Get-ChildItem pour fonctionner de manière plus similaire aux commandes natives *nix ls -R et Windows DIR /S. Get-ChildItem retourne désormais les liens symboliques rencontrés durant une recherche récursive, et n’effectue aucune recherche dans les répertoires ciblés par ces liens.

Extensions de fichier .PS1

Les scripts PowerShell doivent se terminer par .ps1 pour que l’interpréteur comprenne comment les charger et les exécuter dans le processus actuel. Le comportement habituel attendu de PowerShell implique l’exécution de scripts au cours du processus actif. Vous pouvez ajouter le nombre magique #! à un script n’ayant pas d’extension .ps1, mais celui-ci s’exécute alors dans une nouvelle instance de PowerShell, ce qui empêche le script de fonctionner correctement en cas d’échange d’objets. Ce comportement peut être souhaitable lors de l’exécution d’un script PowerShell à partir de Bash ou d’un autre interpréteur de commandes.

Suppression des alias de convenance

PowerShell fournit un ensemble d’alias sous Windows qui correspondent au nom des commandes Linux pour le confort de l’utilisateur. Sur Linux et macOS, les « alias de convenance » pour les commandes de base ls, cp, mv, rm, cat, man, mount et ps ont été supprimés pour permettre à l’exécutable natif de s’exécuter sans spécifier de chemin.

Logging

Sur macOS, PowerShell utilise les API os_log natives pour se connecter au système de journalisation unifiée d’Apple. Sur Linux, PowerShell utilise Syslog, une solution de journalisation très répandue.

Contrôle des tâches

Le contrôle de tâche de type UNIX n’est pas pris en charge dans PowerShell sur Linux ou macOS. Les commandes fg et bg ne sont pas disponibles. Toutefois, vous pouvez utiliser des tâches PowerShell qui fonctionnent sur toutes les plateformes.

Le caractère & placé à la fin d’un pipeline entraîne l’exécution du pipeline comme une tâche PowerShell. Quand un pipeline est lancé en arrière-plan, un objet de traitement est retourné. Une fois que le pipeline s’exécute en tant que travail, toutes les applets de commande *-Job peuvent être utilisées pour la gestion de ce travail. Les variables (en ignorant celles spécifiques au processus) utilisées dans le pipeline étant automatiquement copiées dans la tâche, Copy-Item $foo $bar & fonctionne tout simplement. La tâche s’exécute dans le répertoire actuel au lieu du répertoire de base de l’utilisateur.

Prise en charge de la communication à distance

La communication à distance PowerShell (PSRP) utilisant WinRM sur les plateformes UNIX nécessite une authentification NTLM/Negotiate ou une authentification de base sur HTTPS. PSRP sur macOS prend uniquement en charge l’authentification de base sur HTTPS. L’authentification Kerberos n’est pas prise en charge.

PowerShell prend en charge la communication à distance PowerShell (PSRP) sur SSH pour toutes les plateformes (Windows, Linux et macOS). Pour plus d’informations, consultez Communication à distance SSH dans PowerShell.

Prise en charge de Just Enough Administration (JEA)

PowerShell sur Linux ou macOS ne vous permet pas de créer des points de terminaison d’administration de communication à distance à administration restreinte (JEA).

sudo, exec et PowerShell

PowerShell exécute la plupart des commandes en mémoire (comme Python ou Ruby). De ce fait, vous ne pouvez pas utiliser sudo directement avec les modules intégrés de PowerShell. Vous pouvez exécuter pwsh à partir de sudo. Si vous devez exécuter un cmdlet PowerShell dans PowerShell avec sudo, par exemple sudo Set-Date 8/18/2016, vous devez utiliser sudo pwsh Set-Date 8/18/2016.

Modules inclus sur les plateformes non-Windows

Pour les plateformes non-Windows, PowerShell fournit les modules suivants :

• Microsoft.PowerShell.Archive
• Microsoft.PowerShell.Core
• Microsoft.PowerShell.Host
• Microsoft.PowerShell.Management
• Microsoft.PowerShell.Security
• Microsoft.PowerShell.Utility
• PackageManagement
• PowerShellGet
• PSReadLine
• ThreadJob

Un grand nombre des commandes (cmdlets) couramment disponibles dans PowerShell ne le sont pas sur Linux ou macOS. Souvent, ces commandes ne s’appliquent pas à ces plateformes. Par exemple, les commandes pour les fonctionnalités spécifiques à Windows, telles que le Registre ou les services, ne sont pas disponibles. D’autres commandes, telles que Set-ExecutionPolicy, sont présentes, mais pas fonctionnelles.

Pour obtenir la liste complète des modules et des applets de commande ainsi que les plateformes qu’ils prennent en charge, consultez Historique des versions des modules et des applets de commande.

Modules qui ne sont plus fournis avec PowerShell

Pour différentes raisons de compatibilité, les modules suivants ne sont plus fournis dans PowerShell.

• ISE
• Microsoft.PowerShell.LocalAccounts
• Microsoft.PowerShell.ODataUtils
• Microsoft.PowerShell.Operation.Validation
• PSScheduledJob
• PSWorkflow
• PSWorkflowUtility

Les modules suivants spécifiques à Windows ne sont pas inclus dans PowerShell pour Linux ou macOS.

• CimCmdlets
• Microsoft.PowerShell.Diagnostics
• Microsoft.WSMan.Management
• PSDiagnostics

Applets de commande non disponibles sur les plateformes non-Windows

Certaines cmdlets ont été supprimées de PowerShell. D’autres ne sont pas disponibles ou peuvent fonctionner différemment sur les plateformes non-Windows. Pour obtenir la liste complète des applets de commande supprimées de PowerShell, consultez Applets de commande supprimées de PowerShell.

Microsoft.PowerShell.Core

Les applets de commande suivantes ne sont pas disponibles sur Linux ou macOS :

• 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

Le paramètre ShowWindow de Get-Help n’est pas disponible pour les plateformes non Windows. PowerShell 7.3 a ajouté le cmdlet Switch-Process et la fonction exec pour Linux et macOS. Ces commandes ne sont pas disponibles sur Windows.

Applets de commande Microsoft.PowerShell.Security

Les applets de commande suivantes ne sont pas disponibles sur Linux ou macOS :

• Get-Acl
• Set-Acl
• Get-AuthenticodeSignature
• Set-AuthenticodeSignature
• New-FileCatalog
• Test-FileCatalog

Ces applets de commande sont disponibles uniquement à partir de PowerShell 7.1.

• Get-CmsMessage
• Protect-CmsMessage
• Unprotect-CmsMessage

Applets de commande Microsoft.PowerShell.Management

Les applets de commande suivantes ne sont pas disponibles sur Linux et macOS :

• 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

Les applets de commande suivantes sont disponibles avec des limitations :

• Get-Clipboard – disponible dans PowerShell 7.0+
• Set-Clipboard – disponible dans PowerShell 7.0+
• Restart-Computer – disponible pour Linux et macOS dans PowerShell 7.1+
• Stop-Computer – disponible pour Linux et macOS dans PowerShell 7.1+

Applets de commande Microsoft.PowerShell.Utility

Les applets de commande suivantes ne sont pas disponibles sur Linux et macOS :

• Convert-String
• ConvertFrom-String
• ConvertFrom-SddlString
• Out-GridView
• Out-Printer
• Show-Command

Alias non disponibles sur Linux ou macOS

Le tableau suivant liste les alias disponibles pour Windows, et qui ne sont pas disponibles sur les plateformes non Windows. Ces alias ne sont pas disponibles, car l’alias est en conflit avec une commande native sur ces plateformes.

La table n’inclut pas d’alias non disponibles pour les cmdlets qui n’existent pas sur les plateformes non Windows.

PowerShell Desired State Configuration (DSC)

À partir de PowerShell 7.2, le module PSDesiredStateConfiguration a été supprimé de PowerShell et est publié dans PowerShell Gallery. Pour plus d’informations, consultez l’annonce sur le blog de l’équipe PowerShell. Pour plus d’informations sur l’utilisation de DSC sur Linux, consultez Bien démarrer avec DSC pour Linux. DSC v1.1 et v2.x ne sont pas pris en charge sur macOS. DSC v3 est pris en charge sur Windows, Linux et macOS, mais il est toujours en développement précoce.