Jeffrey Snover raconte le développement de PowerShell

 (corecursive.com)
1 points par GN⁺ 2024-07-05 | 1 commentaires | Partager sur WhatsApp
  • Jeffrey Snover a porté PowerShell pour faire de Windows un OS serveur administrable en ligne de commande, et a dû surmonter la culture Microsoft centrée sur l’interface graphique ainsi que les résistances organisationnelles
  • Les premiers portages d’outils UNIX n’ont pas résolu le problème de l’administration serveur, car Windows reposait sur des API comme le Registry, Active Directory et WMI plutôt que sur des fichiers
  • Après avoir créé 70 commandes basées sur WMI dans WMIC, il a réorienté le projet vers un moteur de génération de commandes fondé sur des métadonnées afin de réduire les goulets d’étranglement et les coûts liés aux tests
  • Monad, le prédécesseur de PowerShell, a démarré dans le sillage de .NET et Longhorn, mais a été écarté de Windows après la réinitialisation de Longhorn, avant d’être relancé grâce au soutien de l’équipe Exchange et de l’organisation Windows Server
  • Snover a accepté une perte de rang et de rémunération pour se concentrer sur PowerShell 1 à 4, et cet outil est devenu la base de l’automatisation de l’administration Windows et de la transition d’Office vers le cloud

Un Windows centré sur l’interface graphique et le problème de l’administration des datacenters

  • PowerShell a été un outil en ligne de commande qui a transformé l’administration des systèmes Windows, mais en interne chez Microsoft, le projet n’a pas été naturellement accepté dès le départ
  • À l’époque, la culture Microsoft était centrée sur l’interface graphique, et l’interface en ligne de commande était considérée comme dépassée, au point qu’une anecdote raconte que Bill Gates aurait dit que command.exe serait la dernière qu’il verrait
  • Le point de départ de Snover chez Microsoft était la conviction qu’il fallait adapter les OS basés sur Windows NT au marché des datacenters et des entreprises
    • L’objectif était de concurrencer les fournisseurs UNIX comme Sun, IBM et HP
    • Intel et l’écosystème matériel ouvert offraient un avantage en matière de coûts, mais les logiciels d’administration serveur n’étaient pas assez bons

Un modèle d’administrateur réduisant la dépendance aux intégrateurs système

  • L’administration des serveurs Windows exigeait de configurer de nombreux serveurs à coups de clics, et comme chaque entreprise avait besoin de configurations différentes, la dépendance aux intégrateurs système pouvait fortement augmenter
  • Snover estimait que si les coûts d’intégration système devenaient trop élevés, l’avantage prix de Windows disparaîtrait
    • Il donnait l’exemple d’une structure de coûts avec 10 pour le matériel, 2 pour le logiciel et 40 pour l’intégrateur système
    • Le fait que la relation client et la valeur passent aux intégrateurs posait aussi problème
  • L’alternative était le modèle UNIX de l’administrateur programmeur
    • Il s’agit de combiner de petits outils pour résoudre des problèmes spécifiques et automatiser les tâches
    • Windows avait besoin non pas seulement “d’administrateurs qui cliquent sur Suivant”, mais d’une couche d’administrateurs professionnels capables de gérer scripts et automatisation

Pourquoi le portage des outils UNIX n’était pas adapté

  • La première solution a consisté à apporter à Windows, via Windows Services for Unix, un shell UNIX et des outils comme AWK/GREP/SED
  • Mais l’architecture d’administration de Windows différait de celle d’UNIX
    • UNIX est un OS centré sur les fichiers : en manipulant des fichiers et en redémarrant des processus, on peut effectuer de nombreuses tâches d’administration
    • Windows avait une architecture où les fonctionnalités se trouvaient derrière des API, comme le Registry, Active Directory et WMI
    • AWK ne s’appliquait pas directement au Registry, SED à Active Directory, ni GREP à WMI
  • WMI offrait des possibilités pour les tâches d’administration, mais il était peu utilisé, et l’équipe de Snover a voulu créer un outil en ligne de commande pour manipuler les objets WMI

WMIC et le moteur fondé sur les métadonnées

  • À l’époque de Windows XP, il fallait créer une interface en ligne de commande basée sur WMI avec une fenêtre de développement limitée à seulement 10 semaines
  • En faisant appel à des ingénieurs contractuels, l’équipe a implémenté 70 opérations, mais c’était très insuffisant par rapport au périmètre nécessaire pour administrer l’ensemble de Windows Server
  • Chez Microsoft, une fonctionnalité ne sortait pas si l’organisation de test ne l’approuvait pas, et plus le nombre de commandes augmentait, plus le goulet d’étranglement des tests grossissait
  • Snover a défendu une approche similaire à la relation entre HTML et le navigateur : considérer chaque commande non pas comme du code, mais comme des métadonnées, et ne tester que le moteur commun
    • L’approche consistait à laisser le moteur générer les commandes, tandis que la configuration de chaque commande était exprimée sous forme de métadonnées, par exemple en XML
    • Pendant les vacances de Noël, il a rédigé les métadonnées et créé 72 commandes
    • Il se souvient que les 70 commandes existantes avaient coûté environ 4 millions de dollars, tandis que le moteur avait coûté environ 60 000 dollars
  • Quand des fonctions comme le filtrage et le formatage ont été ajoutées au moteur, toutes les commandes se sont améliorées en même temps, ce qui a constitué un important précurseur de l’architecture de PowerShell

Longhorn, .NET et Monad

  • Bill Gates, constatant que les utilisateurs de Windows 98 ne migraient pas facilement vers XP, voulait faire de Longhorn un tournant comparable à un nouveau Windows 95
    • Longhorn devait intégrer un mode de développement basé sur .NET, WPF, WCF, un nouveau modèle de stockage, etc.
  • Snover a estimé que .NET pouvait être un moyen d’élargir le périmètre de l’administration Windows
    • L’écriture de fournisseurs WMI n’avait pas généré suffisamment d’élan, mais Bill Gates poussait fortement l’adoption de .NET
    • En plaçant les utilitaires d’administration au-dessus de .NET, il pensait obtenir une couverture plus large
  • Quand une autre organisation a voulu créer un shell en portant K-shell, Snover a expliqué une meilleure approche, sans parvenir à convaincre
  • Il s’est enfermé dans une pièce et a construit un prototype d’environ 10 000 lignes, qui contenait les principes d’architecture centraux de PowerShell
    • Après la démonstration, l’équipe concernée a adopté l’idée, et Snover a pensé que cela pourrait être sa meilleure idée
    • Pour rejoindre ce projet, il a quitté son rôle de chief architect d’un produit/service comptant plusieurs centaines à un millier de personnes, acceptant de fait une rétrogradation

Le Monad Manifesto et la persuasion des équipes

  • La nouvelle équipe a choisi Monad comme nom de projet et, faute d’effectifs, a externalisé une partie du travail en Inde
  • Snover a rédigé le Monad Manifesto afin d’aligner la vision du projet et le chemin vers le succès
    • Il y synthétisait le problème, les approches existantes, la nouvelle approche, la valeur et les éléments de différenciation
    • Il clarifiait la valeur apportée à chaque partie prenante : administrateurs, fournisseurs, équipes de développement, etc.
  • Les différentes équipes de Microsoft avaient beaucoup à faire, et elles n’étaient pas licenciées si elles ne créaient pas d’interface en ligne de commande ; en créer une ne menait pas non plus à une promotion
  • La proposition de Monad était que chaque équipe produit n’écrive que le code manipulant ses propres objets, le reste étant fourni par PowerShell
    • Le formatage, le tri, le filtrage, le parseur, l’exécution à distance, l’élévation de privilèges, etc. étaient fournis côté PowerShell
    • Chaque équipe n’avait qu’à expliquer comment manipuler les objets de son propre domaine
  • L’équipe Active Directory a investi quelques semaines pour créer plusieurs cmdlets, et la forte réaction des groupes d’utilisateurs l’a poussée à poursuivre davantage le travail

Le retour dans Windows après la réinitialisation de Longhorn

  • Dans Longhorn, l’adoption de .NET a été poussée à l’excès, ce qui a amplifié les problèmes
    • Par exemple, la boîte de dialogue Save As de Notepad mettait 1 minute 30 à apparaître à cause d’une boîte de dialogue commune basée sur .NET/WCF, et l’ensemble de travail passait de 15 KB à 15 MB
    • Il est aussi rapporté que les builds nocturnes n’ont pas fonctionné pendant environ 7 mois
  • L’organisation Windows a procédé à une réinitialisation, a retiré le code .NET de Windows, et PowerShell a lui aussi été repoussé hors de Windows
  • Par la suite, PowerShell a subi à plusieurs reprises des pressions pour être annulé, au motif qu’il était à la fois une interface en ligne de commande et basé sur .NET
    • Bill Gates en comprenait la valeur, mais cela n’aidait pas à le défendre au quotidien
    • Le responsable de Windows Server l’a soutenu à des moments critiques
    • L’équipe Exchange a joué un rôle dans l’arrêt des tentatives d’annulation, en mettant en avant une “activité de plusieurs milliards de dollars” qui dépendait de PowerShell
  • Les exigences WinArch pour intégrer .NET dans Windows étaient très strictes, mais l’équipe PowerShell s’est préparée à satisfaire toutes les conditions
  • Quand le responsable de Windows a demandé le retrait de la requête, le program manager a exigé un refus formel, ce qui a ouvert une procédure de revue
    • L’organisation Windows Server détenait ce pouvoir de décision et a estimé que PowerShell satisfaisait aux exigences, ce qui lui a permis de réintégrer Windows

PowerShell 1 à 4 et son impact réel

  • PowerShell 1 est sorti comme composant de Windows Vista
  • Après la sortie, Snover a reçu des conseils l’incitant à faire autre chose et des avertissements sur les risques pour sa carrière, mais il est resté concentré sur la même vision jusqu’à PowerShell 2, 3 et 4
    • Il se souvient que la version 1 a atteint une partie des objectifs, que les versions 2 et 3 ont comblé les fonctionnalités manquantes, et que la vision était presque achevée avec la version 4
  • PowerShell a amené les administrateurs Windows à écrire des scripts et à automatiser des tâches complexes
    • Des groupes d’utilisateurs, des questions-réponses en ligne, du partage de scripts et des présentations en conférence sont apparus
    • Certains administrateurs sont devenus conférenciers professionnels grâce à leur expérience de PowerShell
  • Environ cinq ans plus tard, Snover est devenu Distinguished Engineer, puis Technical Fellow
  • Le responsable d’Office a déclaré que sans PowerShell, la transition d’Office vers le cloud aurait été difficile, et que cette transition d’Office vers le cloud avait également influencé celle d’Azure
    • Auparavant, le provisionnement de serveurs se faisait par clics, ce qui rendait les répétitions et les corrections difficiles
    • Grâce aux scripts, il était possible de passer à l’échelle et, en cas de problème, de modifier les scripts pour réagir

À lire aussi

1 commentaires

 
GN⁺ 2024-07-05
Commentaires sur Hacker News

  • Du point de vue d’un animateur, PowerShell a rencontré une opposition farouche en interne chez Microsoft, et son créateur Jeffrey Snover a même été rétrogradé pour avoir insisté
    Jeffrey avait été recruté à l’origine pour aider Microsoft à apprendre à rivaliser dans les datacenters, mais la culture de l’époque était tellement prisonnière d’une vision du monde centrée sur l’ordinateur personnel qu’il a rencontré de la résistance à chaque étape
    Autre point intéressant : PowerShell est né parce que Windows n’était pas basé sur les fichiers. L’objectif de Jeffrey était l’administration des serveurs, mais sous Windows il n’était pas possible de tout gérer en modifiant simplement des fichiers de configuration ; il fallait appeler plusieurs API et échanger des données structurées, si bien qu’un modèle objet riche était en pratique la seule solution
    La transcription a été produite en combinant une transcription intégrale, la ponctuation revue par Descript et GPT-4, puis une relecture manuelle, mais la qualité n’est peut-être pas aussi bonne qu’espéré

    • Si l’équipe MS-PWSH lit ceci, j’aimerais qu’elle ajoute des fonctionnalités GUI de base qui évitent d’avoir à écrire beaucoup de code .NET à la main
      Ce que j’aime dans PowerShell, c’est que c’est un langage dynamique simple, avec des commandes faciles à chaîner, donc un nouvel ensemble de cmdlets pour créer des interfaces utilisateur simples et des graphiques serait bienvenu
      Par exemple, une fonctionnalité comme Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" semblerait facile à intégrer dans un produit Microsoft, et pourrait supprimer une page de code boilerplate que l’on comprend mal
      Il doit exister des millions d’utilisateurs qui savent faire un peu de programmation de base, mais pour qui des outils comme Java ou C# ne correspondent pas à leur travail. Python convient souvent bien, mais j’aimerais que Microsoft fasse davantage pour créer quelque chose que puissent utiliser non seulement les administrateurs système ou les équipes IT, mais aussi les utilisateurs métier ordinaires
      Si Microsoft investissait davantage pour que PowerShell ne soit pas lent sur des tâches comme l’analyse de fichiers, et ajoutait les fonctionnalités mentionnées plus haut ainsi que des cmdlets de statistique et de calcul scientifique, cela pourrait devenir un outil assez formidable pour qu’un business analyst puisse rapidement créer des logiciels d’amélioration des processus ou des prototypes à transmettre à une équipe de développement
      Microsoft semble considérer qu’il n’existe que trois options : les développeurs logiciels professionnels qui utilisent C#, les tâches IT qui utilisent PowerShell, et Excel pour les utilisateurs métier. Excel est excellent à bien des égards, mais reste assez limité, et VBA+Excel fait partie des écosystèmes les plus contraints que j’aie utilisés. Des langages tiers comme Python ou R constituent bien une quatrième option, mais j’aimerais que Microsoft consacre plus de temps à ce domaine
    • Quand on voit des MVP se plaindre sur GitHub que les investissements supplémentaires promis par Microsoft ne se sont jamais concrétisés, que les changements ne sont pas pris en compte et que de bonnes fonctionnalités sont laissées à l’abandon, on a l’impression que ce n’est plus une priorité de MSFT
      J’aimais PowerShell, y compris ses défauts bizarres, mais je suis passé à autre chose
    • Je me demande pourquoi ils ont tout reconstruit à partir de zéro au lieu d’utiliser Python ou un outil existant similaire
    • J’ai essayé de lire la transcription, mais je n’ai pas réussi à aller jusqu’au bout et je l’ai trouvée un peu difficile à lire
      Pendant la lecture, j’ai supposé qu’elle avait été générée par une machine, mais j’aurais du mal à dire précisément pourquoi ; elle aurait simplement besoin d’un peu d’édition pour être plus lisible
      Cela dit, c’est quand même bien mieux que de ne pas avoir de transcription du tout

  • En tant que développeur ayant longtemps utilisé Bash, j’étais vraiment enthousiaste quand PowerShell est arrivé
    Je pensais qu’on allait enfin avoir un shell sympa pour le développement aussi sur Windows, mais au final je n’ai jamais vraiment assimilé PowerShell, et je continue à utiliser le Bash que je connais bien, même sous Windows
    Je me demande comment les développeurs à l’aise avec les deux les comparent. Est-ce que PowerShell a réellement tenu sa promesse d’être un shell plus efficace et plus moderne, ou bien est-il surtout utilisé parce qu’il est installé par défaut et meilleur que CMD ?

    • J’ai beaucoup utilisé Bash et lu quelques livres dessus, mais je crois fermement qu’il ne faut pas écrire de scripts Bash complexes
      À partir d’environ 50 lignes, j’y vois une odeur de code, et j’ai gardé cette page de côté au cas où je doive convaincre quelqu’un : http://mywiki.wooledge.org/BashPitfalls
      En essayant PowerShell récemment, j’ai trouvé bien plus simple, à la fois comme langage de script et comme langage en ligne de commande, le fait que les commandes renvoient des objets plutôt que du texte, ce qui évite de devoir bricoler du texte de force
      C’est aussi excellent qu’il existe une manière officielle de gérer le parsing des arguments. Tout est cohérent, et dans la fenêtre de ligne de commande on peut pratiquement tout autocompléter parmi les options, à un niveau dont Bash ne peut même pas rêver, ce qui améliore énormément la productivité
      En revanche, les conversions de types introduisent parfois de nouveaux bugs qu’on n’avait pas avec Bash. Aujourd’hui je préfère PWSH, mais j’ai quand même un certain rejet des deux et j’attends leur prochaine évolution naturelle
    • PowerShell est plus verbeux que Bash, et il a des bizarreries comme le fait de désenvelopper automatiquement un tableau de 0 ou 1 élément en scalaire à des moments inattendus, mais il est plus productif et plus lisible
      L’orientation objet est assez utile pour construire des pipelines
      Par exemple, pour regrouper récursivement les fichiers d’un dossier par taille afin de trouver des doublons potentiels, on peut écrire Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count
      Pas besoin de mémoriser une obscure incantation file, ni d’analyser une sortie texte. On reçoit de vrais objets avec des propriétés, et l’autocomplétion par tabulation permet d’en voir la structure
      Si on doit parser du JSON, on peut le faire directement avec Get-Content -Raw whatever.json | ConvertFrom-Json sans jq. Pour convertir du XML en CSV, il suffit d’utiliser ConvertFrom-Xml ou Select-Xml, de faire ensuite le traitement nécessaire, puis d’utiliser ConvertTo-Csv
      Si Get-ChildItem est trop long, on peut utiliser gci, dir ou ls, et si Where-Object est trop long, on peut utiliser where ou ?. Par défaut, il ne distingue même pas la casse
    • J’ai commencé ma carrière sur des terminaux X reliés à des boîtes à pizza SunOS, j’ai écrit des milliers de scripts, dont un bon nombre faisaient plusieurs milliers de lignes
      Il y a quelques années, j’ai dû écrire en PowerShell un système de transfert de données robuste, complexe et entièrement automatisé, et l’expérience a été si bonne que j’ai remplacé tous mes shells sur macOS et Linux par PWSH
      Le meilleur aspect, c’était la puissance du passage d’objets dans le pipeline. Même après avoir extrait et manipulé certaines propriétés d’un objet dans le premier filtre, on pouvait continuer à accéder, dans les filtres plus loin dans le pipeline, aux autres propriétés ainsi qu’aux propriétés créées par le premier filtre
      La cohérence des commandes, de la gestion des erreurs et des propriétés des objets était également excellente
      Ensuite, la nature de mon travail a changé, mon ancienne mémoire musculaire est revenue, et j’ai remis Bash partout. Quand je travaillais et réfléchissais beaucoup dans cet univers, PWSH me paraissait naturel comme shell, mais une fois sorti de cet environnement, penser en PWSH est devenu plus difficile que revenir à Bash
      Ça me manque parfois. Je ne vois rien d’aussi proche dans l’univers des shells, ou du moins aucune alternative assez proche pour justifier l’effort de migration
    • Je ne suis expert dans aucun des deux, mais je les ai pas mal utilisés, et j’ai trouvé PowerShell affreux à utiliser à cause de quelques pièges
      D’abord, il a voulu devenir un langage .NET. Je ne sais pas pourquoi la promesse de .NET — un runtime, plusieurs langages — s’est fanée là où l’écosystème Java a prospéré sans faire cette promesse, mais si je dois écrire du code .NET, autant utiliser C#
      Ensuite, il n’a pas vraiment maîtrisé les bases du shell. Je ne me souviens plus des détails, relégués au passé, mais la gestion de la redirection était cassée, et des choses triviales en Bash étaient pratiquement impossibles dans PowerShell. J’avais l’impression que les développeurs, enthousiasmés par la création de quelque chose de nouveau et puissant, avaient ignoré ce que Bash et les autres faisaient bien
      Enfin, il y a cette obsession d’imposer le format Verb-Object à tous les noms. C’est subjectif, et certains le défendront, mais à mon avis cela rend les scripts laids, la saisie maladroite, sans améliorer réellement la découvrabilité ni la mémorisation
    • Je n’aime pas PowerShell parce qu’il y a d’innombrables façons dont il surprend d’une manière trop différente de Bash
      Le fait d’utiliser la flèche droite au lieu de Tab me perturbe aussi, tout comme l’absence de commandes familières et les règles de nommage très strictes
      Cela dit, PowerShell semble plus capable que Bash quand on le maîtrise bien. Il a un meilleur système de types et facilite la manipulation des arguments, alors que dans Bash les valeurs se rapprochent davantage de chaînes sans forme
      https://github.com/bionicles/tree_plus/blob/main/tests/more_... est une version un peu ancienne de ce que j’utilise pour configurer un environnement de test sur une machine Windows, et cela montre dans une certaine mesure ce qui est possible

  • Quand j’utilisais PowerShell directement, ce n’était pas horrible, mais je ne comprenais pas pourquoi un tableau de longueur 1 était déballé et transformé en son type interne
    À cause de ça, il fallait à chaque fois faire attention au nombre d’éléments pouvant arriver dans le tableau, et au lieu de traiter le cas général, il fallait vérifier à chaque modification, ce qui a provoqué énormément de bugs. Je me demande si quelqu’un sait pourquoi ils ont fait ça

    • Si le comportement autour des tableaux est aussi flou, c’est parce que l’API de sortie des cmdlets l’est aussi vis-à-vis des tableaux
      Une seule fonction, WriteObject, écrit une valeur donnée comme sortie de la cmdlet, et un seul appel produit cette sortie. Si on l’appelle plusieurs fois, le shell n’a d’autre choix que de regrouper toutes ces valeurs dans un tableau en sortie
      Donc si, dans une exécution de cmdlet, WriteObject est appelé une fois, et dans une autre deux fois, le shell ne peut pas savoir que, dans le premier cas, cette sortie unique aurait aussi dû être encapsulée dans un tableau. Mais envelopper systématiquement la sortie des cmdlets dans un tableau gênerait des cmdlets comme Get-Date, où il n’y a sémantiquement qu’un seul résultat
      Pour une raison ou une autre, ils n’ont apparemment pas voulu complexifier l’API pour que les cmdlets puissent elles-mêmes exprimer si leur sortie est sémantiquement unique ou multiple, indépendamment du nombre réel d’appels à WriteObject. Une telle API ne pourrait pas être une propriété statique de la cmdlet, puisque la sortie peut varier fortement selon les paramètres, et un overload WriteObject du type (Object, bool iMightWriteMoreValues) poserait aussi problème, puisqu’il devrait fonctionner avec des tableaux vides. Il aurait sans doute fallu une fonction séparée du genre IWillWriteMultipleValues()
      C’est aussi expliqué ici : https://news.ycombinator.com/item?id=40874873
    • C’est vraiment agaçant. J’ai fini par utiliser le comma hack en ajoutant une virgule au début pour forcer un tableau
      $Ary = @(, "value")
      Pour créer un tableau, surtout un grand tableau, c’est aussi plus performant que +=, donc la possibilité d’assigner une boucle for à un tableau est plutôt sympa. Ce n’était pas intuitif comme façon de remplir un tableau, mais c’était clairement utile
      $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
    • On dirait un cas classique où un logiciel essaie d’être trop intelligent et se plante
      Les développeurs de logiciels devraient toujours se méfier de la tentation de rendre leur logiciel trop intelligent
    • Ça donne l’impression d’une fonctionnalité à moitié finie
      L’autre moitié manquante aurait été de convertir automatiquement une valeur unique en tableau de longueur 1 quand le récepteur attend un tableau
    • On dirait que les langages de niche finissent toujours par avoir ce genre de bizarrerie folle
      Alors qu’il existe déjà quelque chose comme Lua, au lieu de l’utiliser tel quel ou de le modifier légèrement pour obtenir un langage simple, petit, élégant et cohérent, les gens réinventent la roue et n’arrivent même pas à la rendre ronde, une sorte de tragédie sisyphéenne

  • Sauf si j’ai besoin d’une commande PowerShell précise parce qu’il faut interagir avec des sous-systèmes Windows, je me dis : « pourquoi je n’utilise pas Python ? »
    C’est trop verbeux et trop lent pour 90 % de ce qu’on ferait en Bash, et pareil pour ce que, dans une autre vie, j’aurais fait en Perl
    Je me demande souvent pourquoi Microsoft n’a pas construit ça au-dessus de Python, Node ou autre. Je ne me souviens plus de la date de sortie initiale de PowerShell, donc je ne sais pas vraiment ce qui aurait été idéal à l’époque

    • Le REPL Python de base est vraiment médiocre
      Et il n’a pas été conçu pour le travail en console, là où PowerShell est bon. Au lieu de pouvoir prendre le contenu d’un fichier et le passer à une autre commande, il faut gérer soi-même des choses comme les file handles
      Si PowerShell est bon, c’est parce qu’il offre un excellent REPL avec autocomplétion, aucun comportement bizarre sur les espaces, readline[0], et un véritable couteau suisse capable de faire, si nécessaire, tout ce qu’on peut faire avec .NET
      En plus, comme il est orienté objet, on peut se concentrer sur le vrai travail à accomplir au lieu de chercher comment parser la sortie texte d’un vieil utilitaire avec un autre vieil utilitaire
      0 : https://learn.microsoft.com/en-us/powershell/module/psreadli...
    • À l’origine, il était vaguement basé sur Perl et Korn shell
      Dans la première édition de “Powershell in Action” de Bruce Payette, il y a une remarque annexe expliquant que PowerShell ressemble à Perl parce qu’il utilise le symbole @, la variable par défaut $_ et l’opérateur d’appel de fonction &. Apparemment, Perl a réellement été utilisé comme langage racine à une époque, et ces éléments viennent de cette période. Plus tard, la syntaxe a été réorientée pour davantage correspondre à C#, mais ces éléments ont été conservés parce qu’ils fonctionnaient bien, et l’auteur explique qu’en termes perlien, ils contribuaient fortement au « whipupitude quotient » du langage
      Il dit aussi que le cœur du langage PowerShell repose sur la grammaire POSIX 1003.2 du Korn shell, et que, si au départ des idiomes Perl avaient été repris pour des concepts plus avancés comme les tables de hachage, il est devenu clair au fil du projet qu’il valait mieux aligner la syntaxe de PowerShell sur celle de C#
    • PowerShell est sorti 3 ans avant Node
      S’il n’a pas été construit au-dessus d’autre chose, c’est probablement parce que Microsoft contrôlait déjà .NET
      Je ne pense pas que la lenteur vienne de .NET ; ça ressemble plutôt à un problème de conception ou à un manque d’investissement dans les performances
      Cela dit, ça dépend aussi de la version de PS utilisée. Dans mon souvenir, les versions récentes sont plutôt rapides

  • Au travail, j’ai eu la bénédiction de gérer une base de code de procédures stockées SQL Server vieille de plus de 20 ans
    Environ 300 000 lignes de code critique pour le métier, passées par des tests de singe, mais sans gestion de source, jamais vraiment optimisées côté performances, avec du SQL édité et exécuté dans SSMS puis déployé directement en environnement, et bien sûr sans aucun test automatisé
    L’entreprise est centrée sur Windows, on développe sur Mac, et GitHub Actions tourne sur Linux
    J’ai choisi des outils comme PowerShell Core, sqlcmd, docker pour lancer une instance Windows de SQL Server, RedGate SQL Compare pour extraire le schéma et le code depuis les anciens serveurs legacy, tSQLt pour les tests unitaires, TSqlLint pour la conformité du code, SQLFluff pour le respect du style, et Flyway pour le déploiement
    J’ai vite compris que lorsque Windows doit faire partie des plateformes cibles, PowerShell Core est le shell de scripting cross-platform le plus interopérable
    Je n’ai pas trouvé ça agréable à coder. Le moteur regex vient de .NET et a de graves problèmes de backtracking, et le comportement des tableaux était aussi étrange. Lancer des exécutables comme on le souhaite et capturer les flux de sortie était également incohérent, au point qu’il fallait souvent exécuter le processus, rediriger sa sortie vers un fichier temporaire, puis lire ce fichier une fois le processus fils terminé. Même faire passer la sortie standard d’un processus fils dans une variable chaîne était inutilement pénible
    Mais PowerShell Core s’exécute vite. S’il y a bien une chose que Microsoft sait faire, c’est la micro-optimisation. Les outils d’interaction utilisateur, comme les sélecteurs de listes en ASCII art ou les générateurs simples d’invites de saisie, sont aussi très bons. Et tant qu’on évite les dossiers contenant des fichiers verrouillés, la plupart des bizarreries du système de fichiers Windows restent masquées
    En cherchant sérieusement, on peut en général arriver à faire ce qu’on veut. Je recommande

  • Chaque fois que ma carrière s’est rapprochée de l’administration Windows, j’ai vraiment détesté l’expérience, et je suis d’accord avec ces autres impressions
    Mais contrairement à presque tout le reste sous Windows, qui est d’une lourdeur extrême, PowerShell lui-même était en fait plutôt excellent, et a toujours donné l’impression d’avoir été conçu avec soin
    Linux est formidable et restera mon environnement de travail quotidien, mais utiliser Bash est vraiment atroce. Cela dit, comme il est toujours partout, tout le monde commence par y toucher, et on manipulera probablement encore en 2100 des scripts Bash pleins de défauts

  • PowerShell donne vraiment l’impression d’être un produit né de la confiance monopolistique de Microsoft
    Créer un langage avec presque aucun pont syntaxique permettant de venir d’un autre langage, c’était audacieux. Il était impossible de deviner les commandes, paramètres ou drapeaux. Même vu l’ambition de Microsoft, ils auraient dû savoir que des armées d’administrateurs et de programmeurs devraient apprendre et maintenir à la fois PowerShell et des scripts Bash pendant au moins des décennies
    Cette syntaxe extrêmement verbeuse a peut-être fière allure dans des présentations de comité, mais à l’usage fréquent elle se heurte aux limites bien étudiées du cerveau humain. Quand la taille de l’information ou la latence dépasse un certain seuil, l’état de flow se brise, et il faut de la concentration, de la mémorisation explicite et des vérifications répétées. Même avec de la pratique, il est difficile d’exécuter rapidement les incantations shell courantes qui transforment une pensée en réalité, et il faut déjà lutter avec la syntaxe rien qu’en attendant l’autocomplétion puis en décidant s’il faut accepter le mot suivant d’une commande en plusieurs parties
    Quand on cherche pow.. dans le menu Démarrer, on obtient quatre magnifiques choix : PowerShell, PowerShell ISE, et pour chacun une version normale et une version x86. Dans tous les cas, il y a un chargement qui casse le flow. ISE affiche un petit écran de démarrage puis saute ailleurs. Une autre boîte de dialogue vous informe que la session précédente a été fermée sans enregistrer un fichier de script sans nom, mais le rouvre quand même, comme prévu. Alors je ne vois pas pourquoi il me sermonne
    On peut saisir ou coller du texte et exécuter n’importe quel malware, mais dès qu’on veut enregistrer cela dans un fichier et l’exécuter comme script .ps, l’absurde procédure de politique d’exécution se déclenche. C’est peut-être un traumatisme hérité de la mauvaise réputation de sécurité d’Internet Explorer et de Windows à leurs débuts
    J’ai quand même essayé de l’aimer, jusqu’au jour où un script est tombé sur des noms de fichiers contenant des crochets, et PowerShell a interprété ces [1], [2] comme une sorte d’itérateur implicite : https://stackoverflow.com/questions/21008180/copy-file-with-...
    L’une des tâches fondamentales d’un langage de script est de manipuler des fichiers, or les noms de fichiers ne sont pas sous le contrôle du script auteur, et il faut connaître l’espace des noms de fichiers valides sous Windows. Cet épisode a créé un problème de confiance durable envers ce langage
    L’équipe Azure avait visiblement assez de poids au sein de Microsoft pour créer à part une syntaxe saine et lisible comme az find vm, az account show

    • Ce n’est pas vrai. PowerShell s’inspire du shell, de Perl et de plusieurs autres langages, et cela se voit dans sa conception
      L’autre aspect, c’est qu’ils voulaient de la cohérence. La connaissance *NIX s’acquiert en pratique souvent à coups de mémorisation brute. -v veut généralement dire verbose et -h veut généralement dire help, mais en réalité on ne peut faire confiance à rien ni s’y reposer

  • Avec le recul, il est étrange que Microsoft n’ait pas perçu la valeur de rendre toute la configuration de Windows et des applications d’entreprise importantes comme Active Directory et Exchange facile à composer et programmable
    L’idée qu’ils aient proposé comme alternative de se connecter en Remote Desktop pour cliquer partout à la souris est absurde. Automatiser ce genre de tâches est, du moins d’après mon expérience avec AutoHotkey et Window Spy, horriblement difficile et fastidieux

    • Il existe toute une industrie de consultants et d’éditeurs logiciels qui ne veut pas obtenir comme résultat un Windows facilement composable et programmable
      Se connecter en Remote Desktop et cliquer à la souris génère beaucoup d’heures facturables
      L’ironie, c’est qu’il est probablement vrai que le fait que ce soit horriblement difficile et fastidieux est l’une des principales raisons de l’existence de systèmes d’exploitation alternatifs
    • Plus étrange encore, c’est que cette mentalité du « cliquer partout » se soit aussi retrouvée dans Azure
      Il y a longtemps, pour être juste il y a environ 10 ans, un support technique m’a sérieusement proposé Selenium comme meilleure façon d’automatiser un certain paramétrage

  • J’utilise des ordinateurs depuis 1982, mais je n’ai vraiment jamais été utilisateur de Windows, pas une seule fois
    Au début des années 1990, quand Wintel montait en puissance, j’ai suivi la croissance de Linux et de 386BSD, et à la fin des années 1990, quand Win95 et NT dominaient les postes de travail en entreprise, je me suis réfugié sur SPARCStation, Linux et du matériel NeXT abandonné. Après le changement de siècle, j’ai adopté Mac OS, qui venait de devenir conforme à POSIX
    Pendant près d’un demi-siècle, éviter les produits Microsoft a été au cœur de ma politique informatique, avec comme exception notable Applesoft BASIC
    Pourtant, PowerShell est bien

    • Il semble avoir une longue expérience de l’informatique, en particulier des vagues d’innovation qui changent de paradigme
      Mais le deuxième paragraphe esquive en partie ce que le premier laissait attendre ; j’aurais aimé qu’il explique pourquoi il considère PowerShell comme « bon »
    • Je me demande ce qui rend PowerShell meilleur que Bash

  • Quand il faut écrire soi-même des outils en ligne de commande dans un langage de programmation approprié comme le C/C++, l’écart de productivité entre une version faite pour un shell traditionnel et une version faite pour PowerShell est sous-estimé
    En général, je n’ai jamais créé d’outil CLI réellement utile sans accumuler des milliers de lignes de code brouillon. En pratique, il faut gérer l’entrée via pipeline, les paramètres optionnels, les paramètres avec valeur, les valeurs par défaut et leurs surcharges, un mode dry run, diverses exigences de format de sortie, etc. : 90 % de plomberie et seulement 10 % de vrai comportement
    Avec PowerShell, un module C# n’a en gros qu’une vingtaine de lignes de surcharge, et tout le reste correspond au vrai comportement. La productivité est stupéfiante
    On obtient gratuitement la validation des paramètres, l’autocomplétion par tabulation des noms de paramètres, l’entrée et la sortie via pipeline, le formatage, le typage fort, le globbing, etc.

    • Je n’ai jamais utilisé C#, mais je suis d’accord
      Pour la maintenance et les tâches d’administration, je me détourne de plus en plus des outils CLI au profit de langages compilés ou interprétés