Pendant longtemps, la règle tacite dans les cercles Linux a été que PowerShell est une affaire de Windows et que Bash est la vraie affaire. Même moi, j’ai maintenu cette position au début, car les premières itérations de PowerShell semblaient maladroites, étaient uniquement Windows et n’étaient pas largement utilisées par choix. Cette version de PowerShell n’existe plus depuis des années, mais la communauté Linux a toujours la réputation de la rejeter malgré ses progrès.
PowerShell est open source et multiplateforme depuis maintenant une décennie. Il ne s’agit plus d’un outil d’administration uniquement Windows, car il propose également des versions natives pour Linux et macOS. J’avais l’habitude de le considérer comme un terminal que je devais ouvrir chaque fois qu’un script était écrit pour PowerShell, mais je le fermais ensuite sans trop de considération. Une fois que j’ai discuté avec PowerShell pour un vrai projet, j’ai réalisé que ce n’était plus quelque chose que je devais écarter.
Connexes
5 scripts PowerShell que tout utilisateur Windows devrait connaître
PowerShell peut faire beaucoup de choses
Le pipeline d’objets de PowerShell modifie le script
Bash est limité en traitant tout comme une chaîne
Il m’a fallu plus de temps que je ne voudrais l’admettre pour comprendre ce qui rend PowerShell si différent de Bash. Cela a finalement cliqué lorsque j’ai réalisé une différence fondamentale entre les deux : les objets de tuyaux PowerShell et les chaînes de tuyaux Bash. Dans Bash, chaque commande génère du texte, puis vous découvrez comment manipuler ce texte pour en faire quelque chose d’utile. Cela implique généralement beaucoup de tâches pour grep, sed et awk pour analyser la sortie brute, même pour des tâches relativement simples. Ces outils sont puissants et je les utilise toujours constamment, mais je dois admettre que PowerShell simplifie beaucoup de choses.
Voici un exemple rapide qui illustre mon propos. Ce pipeline PowerShell filtre les processus par utilisation du processeur et sélectionne leur nom. Tout ce qui dépasse 10 % d’utilisation du processeur apparaîtra comme sortie :
Get-Process | Where-Object CPU -gt 10 | Select-Object Name
Maintenant, voici comment écrire l’équivalent en Bash :
ps -eo comm,pcpu | awk '$2 > 10 {print $1}'
La différence est immédiatement perceptible rien que dans la lisibilité. Mais cela va encore plus loin que cela, car PowerShell redirige des objets, plutôt que du simple texte, vers chaque commande suivante. Bash utilise awk pour isoler la colonne souhaitée et conserver les processus utilisant plus de 10 % du processeur. Ceci n’est qu’un exemple basique, mais les scripts et pipelines Bash plus complexes utilisent généreusement awk et sed, et ils s’arrêteront si une commande leur remet la sortie dans un format qui s’écarte du tout de ce qu’ils attendent.
Pour les courtes phrases comme l’exemple ci-dessus, la différence n’est pas si importante dans les tâches quotidiennes. Le véritable gain réside dans les scripts plus longs dotés d’une véritable logique, comme le branchement conditionnel, la gestion des erreurs et la transformation des données. C’est là que le modèle objet excelle. Non seulement la plupart de mes scripts PowerShell sont nettement plus courts que leurs équivalents Bash, mais ils sont également beaucoup plus faciles à revoir quelques mois plus tard. Avec les scripts Bash auxquels je n’ai pas touché depuis un moment, il me faut au moins quelques minutes pour étudier le pipeline et me rappeler comment il manipule les données.
Bash gagne toujours en termes de portabilité
Pour mes propres machines, cet avantage disparaît
Bash est carrément omniprésent et ne mène nulle part. Vous le trouverez sur chaque système Linux sur lequel vous vous connectez en SSH, et chaque conteneur Docker vous dépose dans cette invite Bash familière. De plus, les scripts écrits en Bash peuvent être portés sur presque tous les systèmes de type Unix et fonctionner sans aucune modification nécessaire. Même s’il est multiplateforme, PowerShell ne peut pas atteindre ce niveau d’universalité, vous ne pouvez donc vous y attendre que sur les machines Windows et toutes les autres que vous contrôlez.
Au début, je n’étais pas fan de la convention de dénomination verbe-nom, comme Get-ChildItem au lieu de ls, ou Set-Location au lieu de cd. Cela semble verbeux, mais je les ai raccourcis avec des alias et j’ai depuis apprécié la clarté de chaque commande, car même les utilisateurs peu familiers avec PowerShell peuvent déduire la signification de presque n’importe quelle applet de commande d’un simple coup d’œil.
Abonnez-vous à la newsletter pour obtenir des informations sur PowerShell et les scripts
Recevez la newsletter pour une couverture approfondie de PowerShell, Bash et des outils de script associés. La couverture comprend des explications sur les pipelines d’objets, des considérations multiplateformes, des comparaisons de commandes et des exemples concrets qui clarifient les compromis du monde réel.
Obtenir des mises à jour
En vous abonnant, vous acceptez de recevoir des newsletters et des e-mails marketing, et acceptez nos conditions d’utilisation et notre politique de confidentialité. Vous pouvez vous désinscrire à tout moment.
Étant donné que la plupart des scripts que j’écris sont de toute façon destinés à mes propres systèmes, l’avantage de portabilité de Bash n’a pas beaucoup d’importance dans mon laboratoire à domicile, sur mes serveurs privés virtuels ou sur mon poste de travail quotidien. La version multiplateforme de PowerShell se comporte de manière identique sur chaque système sur lequel je l’exécute, j’ai donc tendance à l’utiliser chaque fois que les pipelines deviennent trop lourds dans les scripts Bash complexes.
Quant à mes systèmes Windows, l’exécution de WSL signifie que je peux écrire un script PowerShell qui touche les API Windows et les chemins de fichiers Linux à partir de la même session, sans avoir besoin de changer d’outil. C’est quelque chose que Bash ne peut tout simplement pas faire. Il n’existe pas non plus d’équivalents natifs de Bash pour des choses comme la gestion des erreurs (à l’exception des codes de sortie et set-e, qui sont notoirement peu fiables dans les pipelines) et la gestion des informations d’identification (SecureString). Ces bons à avoir commencent à se sentir essentiels dans des scripts plus longs et plus complexes, ce qui me donne une autre raison d’opter pour PowerShell.
Il est temps de calibrer la réputation de PowerShell
Sans aucun doute, PowerShell ne remplacera pas Bash, et ce n’est pas nécessaire. Mais il a gagné sa place dans la boîte à outils de toute personne effectuant un travail sérieux de script, en particulier dans les environnements Windows ou hybrides. Le pipeline d’objets à lui seul vaut la courbe d’apprentissage, et la plupart des anciennes critiques ne sont plus pertinentes avec les versions natives disponibles sur d’autres systèmes d’exploitation. La plupart des utilisateurs de Linux seraient surpris par ce qu’est devenu PowerShell. Enfin, si jamais ils prenaient la peine de regarder.
*️⃣ Lien source :
PowerShell est une chose Windows, le script a été écrit pour PowerShell, 5 scripts PowerShell que tout utilisateur Windows devrait connaître , ce qui rend PowerShell si différent de Bash, le véritable gain réside dans les scripts plus longs, , , , , Conditions d’utilisation , Politique de confidentialité , la plupart des scripts que j’écris, exécute WSL, remplace Bash,