Jeffrey Snovers Geschichte der PowerShell-Entwicklung

• Jeffrey Snover trieb PowerShell voran, um Windows zu einem per Kommandozeile verwaltbaren Serverbetriebssystem zu machen, und musste dabei die GUI-zentrierte Kultur bei Microsoft sowie organisatorischen Widerstand überwinden
• Die anfängliche Portierung von UNIX-Tools konnte das Problem der Serververwaltung nicht lösen, weil Windows strukturell stärker auf APIs wie Registry, Active Directory und WMI angewiesen war als auf Dateien
• Nachdem er in WMIC 70 WMI-basierte Befehle erstellt hatte, wechselte er zu einer metadatenbasierten Engine zur Befehlserzeugung, um Testengpässe und Kostenprobleme zu reduzieren
• Monad, der Vorläufer von PowerShell, startete im Umfeld von .NET und Longhorn, wurde nach dem Longhorn-Reset jedoch aus Windows verdrängt und überlebte dank der Unterstützung des Exchange-Teams und der Windows-Server-Organisation
• Snover konzentrierte sich trotz Einbußen bei Position und Vergütung auf PowerShell 1 bis 4; das Tool wurde zur Grundlage der Automatisierung der Windows-Verwaltung und der Cloud-Transformation von Office

---

GUI-zentriertes Windows und das Problem der Rechenzentrumsverwaltung

• PowerShell war ein Kommandozeilen-Tool, das die Verwaltung von Windows-Systemen veränderte, wurde intern bei Microsoft aber nicht von Anfang an selbstverständlich akzeptiert
• Die Microsoft-Kultur war damals GUI-zentriert, und Kommandozeilenoberflächen galten als veraltet – bis hin zur Anekdote, dass Bill Gates gesagt habe, man werde command.exe zum letzten Mal sehen
• Snovers Ausgangspunkt beim Eintritt in Microsoft war die Überzeugung, dass ein auf Windows NT basierendes Betriebssystem für Rechenzentren und den Enterprise-Markt verändert werden müsse
  • Ziel war es, mit UNIX-Anbietern wie Sun, IBM und HP zu konkurrieren
  • Intel und das offene Hardware-Ökosystem hatten Kostenvorteile, aber die Serververwaltungssoftware war nicht gut genug

Ein Administratorenmodell, das die Abhängigkeit von Systemintegratoren verringert

• Bei der Windows-Serververwaltung mussten viele Server per Klick konfiguriert werden, und da jedes Unternehmen andere Konfigurationen brauchte, konnte die Abhängigkeit von Systemintegratoren stark wachsen
• Snover sah, dass Windows seinen Preisvorteil verlieren würde, wenn die Kosten für Integratoren zu hoch würden
  • Als Beispiel nannte er eine Kostenstruktur von 10 für Hardware, 2 für Software und 40 für Systemintegratoren
  • Problematisch war auch, dass Kundenbeziehung und Wertschöpfung an die Integratoren übergingen
• Die Alternative war das UNIX-artige Modell des Programmierer-Administrators
  • Dabei werden kleine Tools kombiniert, um spezifische Probleme zu lösen und zu automatisieren
  • Auch Windows brauchte eine Ebene professioneller Administratoren, die mit Skripten und Automatisierung umgehen konnten, statt nur „Weiter“-Buttons zu drücken

Warum die Portierung von UNIX-Tools nicht passte

• Der erste Lösungsansatz bestand darin, mit Windows Services for Unix eine UNIX-Shell und Tools wie AWK/GREP/SED auf Windows zu bringen
• Die Verwaltungsstruktur von Windows unterschied sich jedoch von UNIX
  • UNIX ist ein dateizentriertes Betriebssystem; viele Verwaltungsaufgaben lassen sich erledigen, indem man Dateien manipuliert und Prozesse neu startet
  • Windows hatte eine Struktur, bei der Funktionen hinter APIs wie Registry, Active Directory und WMI lagen
  • AWK passte nicht direkt zur Registry, SED nicht zu Active Directory und GREP nicht zu WMI
• WMI bot Potenzial für Verwaltungsaufgaben, wurde aber kaum genutzt, und Snovers Team wollte ein Kommandozeilen-Tool für den Umgang mit WMI-Objekten entwickeln

WMIC und die metadatenbasierte Engine

• Zur Zeit von Windows XP musste innerhalb eines Zeitfensters von nur zehn Wochen für das Coding eine WMI-basierte Kommandozeilenschnittstelle entstehen
• Mithilfe von Vertragsentwicklern wurden 70 Aufgaben implementiert, doch das war für den Umfang, der zur Verwaltung des gesamten Windows-Servers nötig war, bei weitem nicht genug
• Innerhalb von Microsoft galt: Ohne Freigabe durch die Testorganisation wurde eine Funktion nicht ausgeliefert, und je mehr Befehle hinzukamen, desto größer wurde auch der Testengpass
• Snover setzte sich für einen Ansatz ein, der einzelne Befehle nicht als Code, sondern wie bei HTML und Browsern als Metadaten betrachtete und nur eine gemeinsame Engine testete
  • Der Ansatz bestand darin, dass die Engine Befehle erzeugt und die Einstellungen jedes Befehls als Metadaten in einem Format wie XML beschrieben werden
  • Während der Weihnachtsferien schrieb er die Metadaten und erzeugte 72 Befehle
  • Rückblickend sagte er, die bestehenden 70 Befehle hätten etwa 4 Millionen Dollar gekostet, die Engine dagegen etwa 60.000 Dollar
• Als Funktionen wie Filterung und Formatierung zur Engine hinzukamen, wurden alle Befehle gemeinsam besser; das wurde zu einem wichtigen Vorläufer der PowerShell-Architektur

Longhorn, .NET und Monad

• Bill Gates sah, dass Nutzer von Windows 98 nicht ohne Weiteres auf XP wechselten, und wollte Longhorn zu einem Wendepunkt wie dem neuen Windows 95 machen
  • Longhorn sollte unter anderem .NET-basierte Entwicklung, WPF, WCF und ein neues Speichermodell enthalten
• Snover kam zu dem Schluss, dass .NET ein Mittel sein könnte, um den Verwaltungsumfang von Windows zu erweitern
  • Das Schreiben von WMI-Providern gewann nicht genügend Dynamik, aber Bill Gates trieb die Einführung von .NET stark voran
  • Er sah die Chance, eine größere Abdeckung zu erreichen, wenn Verwaltungs-Utilities auf .NET aufsetzten
• Als eine andere Organisation K-shell portieren wollte, um eine Shell zu bauen, erklärte Snover einen besseren Ansatz, konnte sie aber nicht überzeugen
• Er schloss sich in ein Zimmer ein und baute einen Prototyp mit rund 10.000 Zeilen Code, der bereits die zentralen Architekturprinzipien von PowerShell enthielt
  • Nach der Demo übernahm das Team die Idee, und Snover dachte, dies könne seine beste Idee überhaupt sein
  • Um an diesem Projekt mitzuarbeiten, gab er seine Rolle als Chief Architect eines Produkt- und Servicebereichs mit Hunderten bis Tausenden Mitarbeitern auf und nahm faktisch eine Herabstufung in Kauf

Monad Manifesto und die Überzeugung der Teams

• Das neue Team gab dem Projekt den Namen Monad; wegen Personalmangels wurden Teile der Arbeit nach Indien ausgelagert
• Snover schrieb das Monad Manifesto, um Projektvision und Erfolgspfad aufeinander abzustimmen
  • Es fasste Problem, bisherige Ansätze, neuen Ansatz, Nutzen und Differenzierung zusammen
  • Es machte klar, welchen Wert es für verschiedene Stakeholder wie Administratoren, Provider und Entwicklungsteams bot
• Die einzelnen Teams bei Microsoft hatten viel zu tun, und es war eine Situation, in der man nicht entlassen wurde, wenn man keine Kommandozeilenschnittstelle baute, und in der ein Bau auch nicht automatisch zur Beförderung führte
• Monads Angebot lautete, dass die Produktteams nur den Code schreiben mussten, der ihre eigenen Objekte manipulierte; den Rest stellte PowerShell bereit
  • Formatierung, Sortierung, Filterung, Parser, Remote-Ausführung, Rechteerhöhung und mehr kamen von PowerShell
  • Die Teams mussten nur beschreiben, wie ihre Domain-Objekte manipuliert werden sollten
• Das Active-Directory-Team investierte einige Wochen und baute mehrere Cmdlets; als die Reaktion der User Group stark ausfiel, machte es mit mehr Arbeit weiter

Nach dem Longhorn-Reset zurück zu Windows

• In Longhorn wurde die Einführung von .NET übertrieben vorangetrieben, was die Probleme verschärfte
  • Ein Beispiel war, dass der Save As-Dialog von Notepad wegen eines auf .NET/WCF basierenden gemeinsamen Dialogs erst nach 1 Minute und 30 Sekunden erschien und das Working Set von 15 KB auf 15 MB anwuchs
  • Es gibt auch die Rückschau, dass Nightly Builds etwa sieben Monate lang nicht funktionierten
• Die Windows-Organisation führte einen Reset durch und entfernte .NET-Code aus Windows; auch PowerShell wurde aus Windows herausgedrängt
• Danach stand PowerShell wiederholt unter Abbruchdruck, weil es sowohl eine Kommandozeilenschnittstelle als auch .NET-basiert war
  • Bill Gates verstand den Wert, half aber nicht bei der täglichen Verteidigung
  • Der Verantwortliche für Windows Server unterstützte es in entscheidenden Momenten
  • Das Exchange-Team verhinderte die Einstellung, indem es auf ein „Milliarden-Dollar-Geschäft“ verwies, das von PowerShell abhing
• Die WinArch-Anforderungen, um .NET in Windows aufzunehmen, waren sehr streng, doch das PowerShell-Team bereitete sich darauf vor, alle Bedingungen zu erfüllen
• Als der Windows-Verantwortliche verlangte, den Antrag zurückzuziehen, forderte der Programmmanager eine formelle Ablehnung, wodurch ein Prüfverfahren eröffnet wurde
  • Die Windows-Server-Organisation hatte diese Entscheidungsbefugnis und kam zu dem Schluss, dass PowerShell die Anforderungen erfüllte, sodass es wieder in Windows aufgenommen wurde

PowerShell 1 bis 4 und die tatsächliche Wirkung

• PowerShell 1 wurde als Teil von Windows Vista veröffentlicht
• Nach der Veröffentlichung erhielt Snover den Rat, etwas anderes zu machen, und wurde vor Karrierenachteilen gewarnt, konzentrierte sich aber mit derselben Vision weiter auf PowerShell 2, 3 und 4
  • Rückblickend sagte er, Version 1 habe einige Ziele erreicht, Version 2 und 3 hätten die Funktionen ergänzt, und Version 4 habe die Vision nahezu vollendet
• PowerShell brachte Windows-Administratoren dazu, Skripte zu schreiben und komplexe Aufgaben zu automatisieren
  • Es entstanden User Groups, Online-Fragen und -Antworten, geteilte Skripte und Konferenzvorträge
  • Einige Administratoren wurden durch ihre PowerShell-Erfahrung zu professionellen Speakern
• Snover wurde etwa fünf Jahre später Distinguished Engineer und danach Technical Fellow
• Der Office-Verantwortliche sagte, ohne PowerShell wäre die Cloud-Transformation von Office schwierig gewesen, und die Cloud-Transformation von Office habe auch die Cloud-Transformation von Azure beeinflusst
  • Zuvor war Server-Provisionierung Klickarbeit gewesen, was Wiederholung und Anpassung erschwerte
  • Dank Skripten konnte man skalieren, und wenn Probleme auftraten, konnte man durch Änderungen an den Skripten reagieren

[GN⁺]

Hacker-News-Meinungen

• Aus Sicht des Moderators stieß PowerShell intern bei Microsoft auf extremen Widerstand, und der Erfinder Jeffrey Snover wurde sogar degradiert, weil er es trotzdem durchsetzte.
  Jeffrey wurde ursprünglich eingestellt, um Microsoft dabei zu helfen, zu lernen, wie man im Rechenzentrum konkurriert, aber die damalige Kultur war zu stark an ein Weltbild rund um Personal Computer gebunden, sodass er bei jedem Schritt auf Widerstand stieß.
  Interessant ist außerdem, dass PowerShell entstand, weil Windows nicht dateibasiert war. Jeffreys Ziel war Serververwaltung, aber unter Windows konnte man nicht einfach nur Konfigurationsdateien bearbeiten; man musste mehrere APIs aufrufen und strukturierte Daten austauschen, sodass ein reichhaltiges Objektmodell praktisch der einzige Weg war.
  Das Transkript wurde in der Reihenfolge professionelle Transkription, Descript, Bereinigung der Zeichensetzung mit GPT-4 und eigenes Durchsehen erstellt, aber die Qualität ist möglicherweise nicht so hoch wie erhofft.

  • Wenn das MS-PWSH-Team das sieht: Ich würde mir wünschen, dass grundlegende GUI-Funktionen eingebaut werden, ohne dass man viel .NET-Code direkt schreiben muss.
    Der Grund, warum ich PowerShell mag, ist, dass es eine einfache dynamische Sprache ist und man leicht zu verwendende Befehle verketten kann; daher wäre ein neuer Satz von Cmdlets zum Erstellen einfacher Benutzeroberflächen und Diagramme schön.
    Eine Funktion wie Create-Chart -Type "Bar" -XAxis $Cities -YAxis $GDP -OutputFile "C:/Documents/ProjectAnalysis/CitiesBarGraph.png" zum Beispiel scheint etwas zu sein, das Microsoft leicht ins Produkt aufnehmen könnte, und sie würde eine ganze Seite Boilerplate-Code ersetzen, den man nicht wirklich versteht.
    Es dürfte Millionen von Nutzern geben, die grundlegendes Programmieren beherrschen, für deren Aufgaben Tools wie Java oder C# aber nicht passen. Python passt meist gut, aber ich wünschte, Microsoft würde noch etwas bauen, das nicht nur Serveradministratoren oder IT-Mitarbeiter, sondern auch normale Geschäftsanwender nutzen können.
    Wenn Microsoft mehr investiert, damit PowerShell bei Aufgaben wie Datei-Parsing nicht langsam ist, und die oben genannten Funktionen sowie Cmdlets für Statistik und Wissenschaft ergänzt, könnte daraus ein ziemlich starkes Tool werden, mit dem typische Business-Analysten schnell Software zur Verbesserung ihrer Arbeit oder Prototypen für die Übergabe an Entwicklungsteams erstellen können.
    Microsoft scheint die Optionen als drei Dinge zu sehen: professionelle Softwareentwickler mit C#, IT-Arbeit mit PowerShell und Excel für Business-Anwender. Excel ist in vielerlei Hinsicht großartig, aber ziemlich eingeschränkt, und VBA+Excel gehört zu den eingeschränktesten Ökosystemen, mit denen ich je zu tun hatte. Drittanbieter-Sprachen wie Python und R sind zwar eine vierte Option, aber ich wünschte, Microsoft würde mehr Zeit in diesen Bereich investieren.
  • Wenn man auf GitHub sieht, wie MVPs sich darüber beschweren, dass die von Microsoft versprochenen zusätzlichen Investitionen nicht zustande gekommen sind, Änderungen nicht übernommen wurden und gute Funktionen brachliegen, scheint es inzwischen keine Priorität für MSFT mehr zu sein.
    Ich mochte PowerShell, einschließlich seiner seltsamen Macken, bin aber inzwischen weg.
  • Ich frage mich, warum man es von Grund auf neu gebaut hat, statt Python oder ein ähnliches vorhandenes Tool zu verwenden.
  • Ich habe versucht, das Transkript zu lesen, bin aber nicht bis zum Ende gekommen und fand es etwas schwer zu lesen.
    Beim Lesen vermutete ich, dass es maschinell erzeugt war, kann aber schwer genau sagen, warum; es scheint etwas redaktionelle Bearbeitung zu brauchen, um lesbarer zu werden.
    Trotzdem ist es viel besser, als gar kein Transkript zu haben.

• Als Entwickler, der lange Bash verwendet hat, war ich wirklich gespannt, als PowerShell erschien
  Ich dachte, endlich würde man auch unter Windows eine großartige Shell für die Entwicklung bekommen. Trotzdem habe ich PowerShell danach nie richtig verinnerlicht und nutze auch unter Windows weiter die vertraute Bash
  Mich würde interessieren, wie Entwickler, die beide Shells beherrschen, sie vergleichen. Ich möchte wissen, ob PowerShell das Versprechen einer effizienteren und moderneren Shell tatsächlich eingelöst hat oder ob man sie nur nutzt, weil sie vorinstalliert und besser als CMD ist

  • Ich habe viel Bash verwendet und auch ein paar Bücher gelesen, bin aber fest davon überzeugt, dass man komplexe Bash-Skripte nicht schreiben sollte
    Ab ungefähr mehr als 50 Zeilen sehe ich das als Code Smell, und für den Fall, dass ich jemanden überzeugen muss, habe ich mir diese Seite gespeichert: http://mywiki.wooledge.org/BashPitfalls
    Als ich kürzlich PowerShell ausprobiert habe, war es als Skriptsprache und Kommandozeilensprache deutlich einfacher, dass Befehle keine Texte, sondern Objekte zurückgeben und man Text nicht mit Gewalt bearbeiten muss
    Dass es einen offiziellen Weg für das Parsen von Argumenten gibt, ist ebenfalls großartig. Alles ist einheitlich, und im Kommandozeilenfenster kann man praktisch jede Option per Autovervollständigung ergänzen – ein Niveau, von dem Bash nur träumen kann, was die Produktivität stark erhöht
    Allerdings erzeugen Typkonvertierungen auch neue Bugs, die es in Bash nicht gab. Im Moment bevorzuge ich PWSH, aber bis zu einem gewissen Grad mag ich beide nicht und warte auf die nächste natürliche Weiterentwicklung
  • PowerShell ist ausführlicher als Bash und hat Eigenheiten wie das unerwartete automatische Entpacken von Arrays mit 0 oder 1 Element zu Skalaren, ist aber produktiver und besser lesbar
    Objektorientierung ist beim Aufbau von Pipelines ziemlich nützlich
    Wenn man zum Beispiel in einem Ordner rekursiv Gruppen nach Dateigröße bilden will, um Kandidaten für Duplikate zu finden, kann man Get-ChildItem -File -Recurse | Group-Object -Property Length | Where-Object { $_.Count -gt 1 } | Sort-Object -Property Count schreiben
    Man muss sich keine obskure file-Beschwörung merken und keine Textausgabe parsen. Man bekommt echte Objekte mit Eigenschaften, und die Tab-Vervollständigung kann diese Struktur anzeigen
    Wenn man JSON parsen muss, geht das ohne jq direkt mit Get-Content -Raw whatever.json | ConvertFrom-Json. Um XML in CSV umzuwandeln, nutzt man ConvertFrom-Xml oder Select-Xml, erledigt danach die nötigen Schritte und verwendet ConvertTo-Csv
    Wenn Get-ChildItem zu lang ist, kann man gci, dir oder ls verwenden, und wenn Where-Object zu lang ist, nimmt man where oder ?. Standardmäßig wird außerdem nicht zwischen Groß- und Kleinschreibung unterschieden
  • Ich habe meine Karriere an einem X-Terminal einer SunOS-Pizzabox begonnen, Tausende Skripte geschrieben, viele davon mit mehreren Tausend Zeilen
    Vor einigen Jahren musste ich in PowerShell ein komplexes, unbeaufsichtigt laufendes und robustes Datenübertragungssystem schreiben. Die Erfahrung war so gut, dass ich die Shells auf macOS und Linux komplett auf PWSH umgestellt habe
    Am besten gefiel mir die Stärke, Objekte durch die Pipeline zu reichen. Im ersten Filter konnte ich einige Eigenschaften eines Objekts extrahieren und manipulieren und in späteren Filtern der Pipeline weiterhin auf andere Eigenschaften sowie auf die vom ersten Filter erzeugten Objekteigenschaften zugreifen
    Auch die Konsistenz von Befehlen, Fehlerbehandlung und Objekteigenschaften war sehr gut
    Später änderte sich die Art meiner Arbeit, alte Muskelgedächtnisse kamen zurück, und ich stellte alle Shells wieder auf Bash um. Wenn ich viel in diesem Bereich arbeitete und dachte, fühlte sich PWSH als Shell natürlich an; nachdem ich mich davon entfernt hatte, war es aber schwieriger, in PWSH zu denken, als zu Bash zurückzukehren
    Manchmal vermisse ich es. In diesem Shell-Bereich kommt nichts so nah heran, jedenfalls keine Alternative, die nah genug wäre, um den Umstellungsaufwand zu rechtfertigen
  • Ich bin in keiner von beiden Experte, habe aber beide recht viel benutzt, und PowerShell fühlte sich wegen einiger Fallstricke schrecklich an
    Erstens wollte sie eine .NET-Sprache sein. Ich weiß nicht, warum das .NET-Versprechen von einer Runtime und mehreren Sprachen bei Java auch ohne ein solches Versprechen aufblühte, während es bei .NET verkümmerte, aber wenn man .NET-Code schreiben will, ist C# meiner Ansicht nach die bessere Wahl
    Zweitens hat sie die Grundlagen einer Shell nicht richtig hinbekommen. Die Details habe ich inzwischen der Vergangenheit überlassen und erinnere mich nicht mehr genau, aber die Umleitung war kaputt, und Dinge, die in Bash trivial waren, waren in PowerShell nahezu unmöglich. Ich hatte den Eindruck, dass die Entwickler so begeistert davon waren, etwas Neues und Mächtiges zu bauen, dass sie ignorierten, was Bash und andere gut konnten
    Drittens gibt es diese Fixierung darauf, für alle Namen ein Verb-Object-Format zu verlangen. Das ist subjektiv und hat sicher Befürworter, aber meiner Meinung nach macht es Skripte hässlich, das Tippen unbeholfen und verbessert Auffindbarkeit oder Merkbarkeit nicht wirklich
  • Ich mag PowerShell nicht, weil es unzählige Stellen gibt, an denen sie einen auf eine ganz andere Weise überrascht als Bash
    Dass man statt Tab den Rechtspfeil verwenden soll, verwirrt ebenfalls, und auch das Fehlen vertrauter Befehle sowie die strengen Konventionen bei der Benennung sind unbequem
    Wenn man sie aber gut kennt, wirkt PowerShell leistungsfähiger als Bash. Sie hat ein besseres Typsystem und Argumente lassen sich leichter handhaben, während Bash-Werte eher formlose Strings sind
    https://github.com/bionicles/tree_plus/blob/main/tests/more_... ist eine etwas ältere Version, die ich zum Einrichten einer Testumgebung auf Windows-Maschinen verwende, und sie zeigt einigermaßen, was möglich ist

• Als ich PowerShell selbst benutzte, war es nicht furchtbar, aber ich habe nie verstanden, warum ein Array der Länge 1 aus dem Array ausgepackt und in den inneren Typ umgewandelt wird.
  Dadurch musste man jedes Mal darauf achten, wie viele Elemente in einem Array ankommen können, und statt es allgemein zu behandeln, musste man bei jeder Änderung nachprüfen, was zu enorm vielen Bugs führte. Ich frage mich, ob jemand weiß, warum man das so gemacht hat.

  • Der Grund, warum es rund um Arrays so locker zugeht, ist, dass auch die cmdlet-Ausgabe-API in Bezug auf Arrays locker ist.
    Eine einzelne Funktion namens WriteObject schreibt einen gegebenen Wert als Ausgabe eines cmdlets; ruft man sie einmal auf, ist genau das die Ausgabe. Ruft man sie mehrmals auf, bleibt der Shell nichts anderes übrig, als aus all diesen Werten ein Array als Ausgabe zu machen.
    Wenn ein cmdlet also bei einer Ausführung WriteObject nur einmal und bei einer anderen zweimal aufruft, kann die Shell im ersten Fall nicht wissen, dass sie auch diese einzelne Ausgabe in ein Array hätte einpacken müssen. Andererseits würde es cmdlets wie Get-Date, die semantisch nur ein einziges Ergebnis haben, stören, wenn cmdlet-Ausgaben immer in Arrays verpackt würden.
    Aus irgendeinem Grund wollte man die API offenbar nicht so kompliziert machen, dass ein cmdlet selbst ausdrücken kann, ob seine Ausgabe semantisch eine Einzel- oder Mehrfachausgabe ist, unabhängig von der tatsächlichen Zahl der WriteObject-Aufrufe. Eine solche API könnte keine statische Eigenschaft des cmdlets sein, weil sich die Ausgabe je nach Parametern stark unterscheiden kann; und ein WriteObject-Overload wie (Object, bool iMightWriteMoreValues) ist ebenfalls problematisch, weil er auch mit leeren Arrays funktionieren müsste. Vermutlich hätte man eine separate Funktion IWillWriteMultipleValues() gebraucht.
    Das wird auch hier erklärt: https://news.ycombinator.com/item?id=40874873
  • Das ist wirklich nervig. Ich habe angefangen, den Comma Hack zu verwenden, bei dem man ein Komma voranstellt, um ein Array zu erzwingen.
    $Ary = @(, "value")
    Beim Erzeugen von Arrays, besonders großer Arrays, ist es performanter als +=, daher ist auch die Möglichkeit, einem Array eine for-Schleife zuzuweisen, ziemlich praktisch. Als Methode zum Befüllen eines Arrays ist es nicht intuitiv, aber definitiv nützlich.
    $Ary = foreach ($Obj in $Objs) { @{ foo = $Obj.foo } }
  • Das klingt nach einem klassischen Fall von Software, die daran scheitert, zu clever sein zu wollen.
    Softwareentwickler sollten immer auf der Hut vor der Versuchung sein, ihre Software zu clever zu machen.
  • Es fühlt sich wie ein halb ausgebackenes Feature an.
    Die fehlende andere Hälfte wäre wohl gewesen, einen Einzelwert automatisch in ein Array der Länge 1 umzuwandeln, wenn die empfangende Seite ein Array erwartet.
  • Nischensprachen scheinen jedes Mal solche verrückten Eigenheiten zu bekommen.
    Obwohl es schon Dinge wie Lua gibt, wirkt es wie eine Sisyphos-Tragödie: Statt so etwas einfach zu verwenden oder leicht anzupassen, um eine einfache, kleine, elegante und konsistente Sprache zu bekommen, erfinden die Leute das Rad neu und schaffen es dann nicht einmal, es rund zu machen.

• Wenn man nicht mit Windows-Subsystemen interagieren muss und deshalb bestimmte PowerShell-Befehle braucht, denke ich mir: „Warum benutze ich nicht Python?“
  Für 90 % der Dinge, die man mit Bash erledigen würde, ist es zu ausführlich und zu langsam, und dasselbe gilt für Dinge, die ich in einem anderen Leben mit Perl gemacht hätte.
  Ich frage mich oft, warum Microsoft es nicht auf etwas wie Python oder Node aufgebaut hat. Ich erinnere mich nicht, wann PowerShell erstmals herauskam, daher bin ich mir nicht sicher, was damals ideal gewesen wäre.

  • Die Standard-REPL von Python ist wirklich miserabel.
    Außerdem ist sie nicht für die Konsolenarbeit ausgelegt, in der PowerShell gut ist. Dinge, bei denen man einfach Dateiinhalte nehmen und an einen anderen Befehl weiterreichen sollte, muss man dort selbst über File-Handle-Management o. Ä. erledigen.
    Was PowerShell gut macht: eine hervorragende REPL mit Autovervollständigung, kein merkwürdiges Whitespace-Verhalten, readline[0] und, wenn nötig, ein Schweizer Taschenmesser, mit dem man alles tun kann, was mit .NET möglich ist.
    Außerdem ist es objektorientiert, sodass man sich auf die eigentliche Aufgabe konzentrieren kann, statt herauszufinden, wie man die textbasierte Ausgabe eines alten Utilities mit einem anderen alten Utility parst.
    0: https://learn.microsoft.com/en-us/powershell/module/psreadli...
  • Ursprünglich war es lose an Perl und die Korn Shell angelehnt.
    In der ersten Ausgabe von Bruce Payettes „Powershell in Action“ gibt es eine Nebenbemerkung, dass PowerShell wie Perl aussieht, weil es das @-Zeichen, die Standardvariable $_ und den Funktionsaufrufoperator & verwendet. Tatsächlich habe man eine Zeit lang Perl als Ursprungssprache verwendet, und diese Elemente stammten aus dieser Phase. Später wurde die Syntax stärker an C# angepasst, aber diese Elemente funktionierten gut und wurden deshalb beibehalten; in Perl-Begriffen hätten sie erheblich zum „whipupitude quotient“ der Sprache beigetragen.
    Außerdem heißt es, die Kernsprache von PowerShell basiere auf der POSIX-1003.2-Syntax der Korn Shell; ursprünglich habe man für fortgeschrittene Konzepte wie Hash-Tabellen Perl-Idiome übernommen, doch im Verlauf des Projekts sei klar geworden, dass es sinnvoller sei, die PowerShell-Syntax an C# auszurichten.
  • PowerShell erschien drei Jahre vor Node.
    Dass es nicht auf etwas anderem basierte, lag wahrscheinlich daran, dass Microsoft .NET kontrollierte.
    Ich glaube nicht, dass .NET der Grund für die Langsamkeit ist; es dürfte eher ein Designproblem oder zu geringe Investitionen in Performance sein.
    Allerdings hängt es davon ab, welche Version von PS man verwendet. Soweit ich mich erinnere, sind die neuesten Versionen ziemlich schnell.

• Bei der Arbeit hatte ich das Glück, mich mit einer über 20 Jahre alten Codebasis aus SQL-Server-Stored-Procedures herumschlagen zu dürfen.
  Rund 300.000 Zeilen geschäftskritischer Code, der per Monkey Testing erprobt war, aber keine Quellcodeverwaltung hatte, nie ordentlich auf Performance getunt wurde, in SSMS bearbeitet und ausgeführt und so in Umgebungen deployt wurde – und natürlich gab es keine automatisierten Tests.
  Das Unternehmen ist Windows-zentriert, entwickelt wird auf dem Mac, und in GitHub Actions läuft Linux.
  Wir entschieden uns für Tools wie PowerShell Core, sqlcmd, Docker zum Ausführen einer Windows-SQL-Server-Instanz, RedGate SQL Compare zum Extrahieren von Schema und Code aus den bestehenden Legacy-Servern, tSQLt für Unit-Tests, TSqlLint für Code-Konformität, SQLFluff für Style-Konformität und Flyway für Deployments.
  Wenn Windows eine der Plattformen sein muss, merkt man schnell, dass PowerShell Core die interoperabelste Cross-Plattform-Scripting-Shell ist.
  Spaß gemacht hat das Coding nicht. Die Regex-Engine kommt aus .NET und hat fatale Backtracking-Probleme, und auch das Verhalten von Arrays war merkwürdig. Executables so zu starten, wie man es will, und ihre Output-Streams abzugreifen, war ebenfalls inkonsistent; oft musste man einen Prozess starten, die Ausgabe in eine temporäre Datei umleiten und diese Datei lesen, sobald der Child-Prozess beendet war. Auch die Standardausgabe eines Child-Prozesses in eine String-Variable zu pipen, war unnötig umständlich.
  Aber PowerShell Core ist schnell in der Ausführung. Wenn Microsoft etwas gut kann, dann Mikro-Optimierung. Auch die Tools zur Interaktion mit Nutzern sind gut, etwa ein ASCII-Art-Listenauswähler oder einfache Generatoren für Eingabe-Prompts. Wenn man Ordner mit gesperrten Dateien meidet, kaschiert es auch die meisten seltsamen Eigenheiten des Windows-Dateisystems.
  Wenn man intensiv sucht, bekommt man im Großen und Ganzen hin, was man will. Kann ich empfehlen.

• Ich stimme den anderen Eindrücken zu, dass ich diese Erfahrung wirklich gehasst habe, wann immer meine Karriere näher an Windows-Administration heranrückte.
  Aber anders als praktisch alles andere an Windows, das extrem klobig ist, war PowerShell selbst tatsächlich ziemlich gut und fühlte sich immer durchdacht gestaltet an.
  Linux ist großartig und ich werde es auch weiterhin als tägliche Arbeitsumgebung nutzen, aber Bash zu verwenden ist wirklich furchtbar. Trotzdem ist es überall immer vorhanden, deshalb greifen alle zuerst dazu, und vermutlich werden wir auch im Jahr 2100 noch mit Bash-Skripten samt all ihren Macken zu tun haben.

• PowerShell wirkt wirklich wie ein Produkt aus Microsofts proprietärem Selbstbewusstsein.
  Eine Sprache zu entwerfen, die kaum syntaktische Anknüpfungspunkte für Umsteiger aus anderen Sprachen bietet, ist schon kühn. Befehle, Parameter und Flags ließen sich nicht erraten oder ableiten. Selbst angesichts von Microsofts Ambitionen hätte man wissen müssen, dass Heerscharen von Administratoren und Programmierern mindestens jahrzehntelang PowerShell- und Bash-Skripte parallel lernen und pflegen müssten.
  Die extrem wortreiche Syntax mag in Ausschusspräsentationen gut aussehen, kollidiert aber bei häufiger praktischer Nutzung mit gut erforschten Grenzen des menschlichen Gehirns. Wenn Informationsgröße oder Latenz eine bestimmte Schwelle überschreiten, bricht der Flow ab, und es braucht Konzentration, explizites Auswendiglernen und erneutes Prüfen. Selbst mit Übung ist es schwer, die üblichen Shell-Beschwörungen, mit denen Gedanken in Realität verwandelt werden, schnell auszuführen; schon das Warten auf Autovervollständigung und die Entscheidung, ob man das nächste Wort eines mehrteiligen Befehls übernimmt, zwingt einen zum Ringen mit der Syntax.
  Wenn man im Startmenü nach pow.. sucht, bekommt man die schönen vier Optionen PowerShell, PowerShell ISE sowie jeweils die normale und die x86-Version. Egal welche man nimmt, es lädt und unterbricht den Flow. ISE zeigt einen kleinen Splash-Screen und springt an eine andere Position. Ein weiterer Dialog teilt mit, dass man in der letzten Sitzung eine unbenannte Skriptdatei geschlossen hat, ohne sie zu speichern, öffnet sie aber ohnehin wie erwartet wieder. Warum also die Standpauke?
  Man kann Text eintippen oder kopieren und damit beliebigen Schadcode ausführen, aber sobald man ihn als Datei speichert und als .ps-Skript ausführen will, beginnt ein lächerliches Verfahren rund um Execution Policies. Vielleicht war das ein Trauma aus dem schlechten Sicherheitsruf des frühen Internet Explorer und von Windows.
  Trotzdem habe ich versucht, es zu lieben, bis ein Skript eines Tages auf Dateinamen mit eckigen Klammern traf und PowerShell diese [1], [2] implizit als eine Art Iterator interpretierte: https://stackoverflow.com/questions/21008180/copy-file-with-...
  Eine Kernaufgabe einer Skriptsprache ist der Umgang mit Dateien; Dateinamen liegen nicht unter der Kontrolle des Skriptautors, und den unter Windows gültigen Namensraum sollte man kennen. Durch diese Sache entstand bei mir ein lang anhaltendes Vertrauensproblem mit der Sprache.
  Das Azure-Team hatte innerhalb von Microsoft offenbar genug Macht, um mit az find vm, az account show eine eigene, vernünftige und lesbare Syntax zu schaffen.

  • Dem ist nicht so. PowerShell wurde von Shells, Perl und mehreren anderen Sprachen inspiriert, und diese Spuren sieht man im Design.
    Die andere Seite war der Wunsch nach Konsistenz. *NIX-Wissen erwirbt man in der Praxis durch stumpfes Auswendiglernen. -v bedeutet meistens verbose und -h meistens help, aber wirklich auf nichts davon kann man sich verlassen.

• Rückblickend ist es seltsam, warum Microsoft den Wert nicht gesehen hat, alle Einstellungen von Windows und wichtigen Enterprise-Anwendungen wie Active Directory und Exchange auf leicht kombinierbare und programmierbare Weise konfigurierbar zu machen.
  Die Vorstellung, als Alternative vorzuschlagen, sich per Remote Desktop einzuloggen und mit der Maus herumzuklicken, ist absurd. Solche Aufgaben zu automatisieren ist – zumindest nach meiner Erfahrung mit AutoHotkey und Window Spy – furchtbar schwierig und lästig.

  • Es gibt eine ganze Branche von Beratern und Softwareanbietern, die nicht wollen, dass Windows-Einstellungen leicht kombinierbar und programmierbar werden.
    Sich per Remote Desktop einzuloggen und mit der Maus herumzuklicken erzeugt viele abrechenbare Stunden.
    Ironischerweise ist die Tatsache, dass so etwas furchtbar schwierig und lästig ist, wahrscheinlich einer der Hauptgründe, warum alternative Betriebssysteme existieren.
  • Noch merkwürdiger ist, dass diese Denkweise des „Herumklickens“ auch in Azure Einzug gehalten hat.
    Früher – fairerweise muss man sagen, vor etwa zehn Jahren – bekam ich einmal von einem Support-Techniker den ernst gemeinten Vorschlag, der beste Weg zur Automatisierung einer bestimmten Einstellung sei Selenium.

• Ich nutze seit 1982 Computer, war aber wirklich kein einziges Mal Windows-Nutzer.
  Als Wintel Anfang der 1990er aufkam, verfolgte ich das Wachstum von Linux und 386BSD; als Win95 und NT Ende der 1990er die Business-Desktops dominierten, zog ich mich auf SPARCStation, Linux und eingestellte NeXT-Hardware zurück. Nach der Jahrtausendwende nahm ich das neu POSIX-konforme Mac OS an.
  Fast ein halbes Jahrhundert lang war es ein Kernpunkt meiner Computing-Policy, Microsoft-Produkte zu meiden; die nennenswerte Ausnahme war vielleicht Applesoft BASIC.
  Aber PowerShell ist gut.

  • Offenbar hat die Person viel Erfahrung mit Computing, insbesondere mit Wellen von Innovationen, die Paradigmen verändert haben.
    Allerdings weicht der zweite Absatz den Erwartungen, die der erste Absatz weckt, bewusst aus; ich hätte gern erklärt bekommen, warum PowerShell als „gut“ angesehen wird.
  • Ich frage mich, was PowerShell besser macht als Bash.

• Wenn man Kommandozeilen-Tools direkt in einer richtigen Programmiersprache wie C/C++ schreiben muss, wird der Produktivitätsunterschied zwischen Tools für traditionelle Shells und solchen für PowerShell unterschätzt.
  Üblicherweise habe ich noch kein nützliches CLI-Tool gebaut, ohne dass es aus Tausenden Zeilen oder weniger an unordentlichem Code bestand. Meist muss man Pipeline-Eingaben, optionale Parameter, Parameter mit Werten, Default-Werte und Overrides, Dry-Run-Modus, verschiedene Anforderungen an Ausgabeformate usw. behandeln, sodass 90 % Beiwerk sind und nur 10 % die eigentliche Funktion.
  In PowerShell hat ein C#-Modul im Grunde nur etwa 20 Zeilen Overhead, der Rest ist echte Funktionalität. Die Produktivität ist erstaunlich.
  Parametervalidierung, Tab-Vervollständigung von Parameternamen, Pipeline-Ein- und -Ausgabe, Formatierung, starke Typisierung, Globbing usw. bekommt man alles gratis dazu.

  • Ich habe C# nie benutzt, stimme aber zu.
    Bei Wartungs- und Administrationsaufgaben verlagert sich immer mehr von CLI-Tools hin zu kompilierten oder interpretierten Sprachen.