Ist PowerShell bereit, meine Cygwin-Shell unter Windows zu ersetzen?

Question

Ich bin am Überlegen, ob ich PowerShell lernen soll, oder ob ich einfach bei Cygwin /Perl-Skripte/Unix-Shell-Skripte, usw.

Der Vorteil von PowerShell wäre, dass die Skripte leichter von Teamkollegen verwendet werden könnten, die nicht über Cygwin verfügen; allerdings weiß ich nicht, ob ich wirklich so viele Skripte für allgemeine Zwecke schreiben würde, oder ob die Leute sie überhaupt verwenden würden.

Die Unix-Skripterstellung ist so leistungsstark, kommt PowerShell dem nahe genug, um einen Wechsel zu rechtfertigen?

Hier sind einige der spezifischen Dinge (oder Entsprechungen), nach denen ich in PowerShell suchen würde:

• grep
• sortieren
• uniq
• Perl (wie nah kommt PowerShell an die Fähigkeiten von Perl heran?)
• AWK
• sed
• file (der Befehl, der Dateiinformationen liefert)
• usw.

Answer 1

Ich habe erst vor kurzem begonnen, mich ernsthaft mit der PowerShell zu beschäftigen. Obwohl ich in den letzten sieben Jahren fast ausschließlich in einer Windows-Umgebung gearbeitet habe, komme ich von einem Unix-Hintergrund und ertappe mich ständig dabei, wie ich versuche, meine Interaktionserfahrung unter Windows "unix-fit" zu machen. Das ist, gelinde gesagt, frustrierend.

Es ist nur fair, PowerShell mit etwas zu vergleichen wie バッシュ , tcsh , oder zsh da Dienstprogramme wie grep , sed , awk , finden. usw. sind streng genommen nicht Teil der Shell; sie werden jedoch immer Teil jeder Unix-Umgebung sein. Das heißt, ein PowerShell-Befehl wie Select-String hat eine sehr ähnliche Funktion wie grep y ist als Kernmodul in PowerShell gebündelt ... daher können die Grenzen ein wenig verwischt sein.

Ich denke, das Wichtigste ist Kultur und die Tatsache, dass die jeweiligen Tool-Sets ihre jeweiligen Kulturen verkörpern:

• Unix ist ein dateibasiert (im Allgemeinen, nicht Unicode) textbasiert Kultur. Konfigurationsdateien sind fast ausschließlich Text Dateien. Windows hingegen war in Bezug auf die Konfigurationsformate schon immer weitaus strukturierter - die Konfigurationen werden im Allgemeinen in proprietären Datenbanken (z. B. der Windows-Registrierung) gespeichert, für deren Verwaltung spezielle Tools erforderlich sind.

• Die Unix-Verwaltungsschnittstelle (und seit vielen Jahren auch die Entwicklungsschnittstelle) ist traditionell die Kommandozeile und das virtuelle Terminal. Windows begann als grafische Benutzeroberfläche, und die Verwaltungsfunktionen haben sich erst in letzter Zeit von der Kommandozeile entfernt. ausschließlich GUI-basiert. Wir können davon ausgehen, dass die Unix-Erfahrung auf der Kommandozeile angesichts des deutlichen Vorsprungs vor der PowerShell reichhaltiger und ausgereifter ist, und meine Erfahrung stimmt damit überein. Meiner Erfahrung nach ist dies der Fall:

  • Die Unix-Verwaltungserfahrung ist darauf ausgerichtet, Dinge mit einer minimalen Anzahl von Tastenanschlägen einfach zu erledigen; dies ist wahrscheinlich das Ergebnis der historischen Situation, einen Server über eine langsame 9600-Baud-Einwahlverbindung verwalten zu müssen. PowerShell verfügt über Aliase, mit denen sich die recht ausführlichen Verb-Nomen Standard, aber das Kennenlernen dieser Aliasnamen ist etwas mühsam (kennt jemand eine bessere Lösung als: alias | where {$_.ResolvedCommandName -eq "<command>"} ?).

    Ein Beispiel für die vielfältigen Möglichkeiten der Manipulation von Geschichte:

    iptables Befehle sind oft langatmig und ihre Wiederholung mit geringfügigen Unterschieden wäre mühsam, wenn es nicht eine der vielen nützlichen Funktionen zur Manipulation der Geschichte gäbe, die in バッシュ Daher wird eine iptables-Regel wie die folgende eingefügt:

    iptables -I camera-1-internet -s 192.168.0.50 -m state --state NEW -j ACCEPT

    ein zweites Mal für eine andere Kamera (" camera-2 "), ist nur ein Fall von Ausstellen:

    !!:s/-1-/-2-/:s/50/51

    was bedeutet: "Führe den vorherigen Befehl aus, aber ersetze ihn durch -1- mit -2- y 50 mit 51 .

  • Die Unix-Erfahrung ist für Tipper optimiert; man kann so ziemlich alles tun, ohne die "Home"-Position zu verlassen. Zum Beispiel in バッシュ unter Verwendung der Emacs Tastenkombinationen (ja, Bash unterstützt auch vi Bindungen), das Durchlaufen der Historie erfolgt mit Ctrl-P y Ctrl-N während das Bewegen zum Anfang und Ende einer Zeile mit Ctrl-A y Ctrl-E bzw. ... und das ist noch lange nicht alles. Versuchen Sie selbst die einfachste Navigation in der PowerShell-Konsole, ohne sich von der Ausgangsposition zu bewegen, und Sie haben ein Problem.

  • Einfache Dinge wie das vielseitige Paging (a la weniger ) unter Unix scheinen in der PowerShell nicht sofort verfügbar zu sein, was ein wenig frustrierend ist, und ein reichhaltiges Editor-Erlebnis gibt es auch nicht. Natürlich kann man immer Tools von Drittanbietern herunterladen, die diese Lücken füllen, aber es wäre schön, wenn diese Dinge einfach "da" wären, wie sie es bei so ziemlich jeder Unix-Variante sind.

• Die Windows-Kultur, zumindest in Bezug auf die System-APIs, wird weitgehend von den unterstützenden Frameworks angetrieben, d. h., COM y .NET die beide stark strukturiert und objektbasiert sind. Auf der anderen Seite erfolgt der Zugriff auf Unix-APIs traditionell über eine Dateischnittstelle ( /dev y /proc ) oder (nicht objektorientierte) Bibliotheksaufrufe im C-Stil. Es ist also keine Überraschung, dass die Skripterfahrungen mit den jeweiligen Betriebssystemparadigmen übereinstimmen. PowerShell ist von Natur aus strukturiert (alles ist ein Objekt) und バッシュ -und-Freunde Datei-basiert. Die strukturierte API, die einem PowerShell-Programmierer zur Verfügung steht, ist sehr umfangreich (im Wesentlichen so umfangreich wie der bestehende Satz von Standard-APIs). COM und .NET-Schnittstellen).

Kurz gesagt, obwohl die Skripting-Funktionen von PowerShell wohl leistungsfähiger sind als バッシュ (insbesondere wenn man die Verfügbarkeit der .NET BCL ), die interaktiv Erfahrung ist deutlich schwächer, vor allem, wenn Sie von einer rein tastaturgesteuerten, konsolenbasierten Perspektive ausgehen (wie es viele Unix-Fans tun).

Answer 2

Ich bin beileibe kein sehr erfahrener PowerShell-Benutzer, aber das bisschen, das ich kennengelernt habe, hat mich sehr beeindruckt. Man kann die eingebauten Cmdlets miteinander verknüpfen, um so ziemlich alles zu tun, was man auch an einer Unix-Eingabeaufforderung tun könnte, und es gibt einige zusätzliche Funktionen für Dinge wie den Export in CSV- und HTML-Tabellen sowie für tiefer gehende Aufgaben der Systemverwaltung.

Und wenn Sie wirklich etwas brauchen wie sed gibt es immer UnixUtils o GnuWin32 die Sie recht einfach in PowerShell integrieren können.

Als langjähriger Unix-Benutzer hatte ich allerdings ein paar Schwierigkeiten, mich an das Schema der Befehlsbenennung zu gewöhnen, und ich hätte sicherlich mehr davon profitiert, wenn ich mehr .NET-Kenntnisse gehabt hätte.

Ich bin also der Meinung, dass es sich lohnt, das Programm zu erlernen, wenn die Tatsache, dass es nur für Windows verfügbar ist, kein Problem darstellt.

Answer 3

Wenn Sie PowerShell mit der Kombination Cygwin/Perl/Shell vergleichen, sollten Sie beachten, dass PowerShell nur den "Shell"-Teil dieser Kombination darstellt.

Sie können jedoch jeden Befehl von PowerShell aus aufrufen, genauso wie Sie es von cmd.exe oder Cygwin aus tun. Es tut no die angegebenen Funktionen neu zu implementieren, und es ist sicherlich nicht mit Perl vergleichbar.

Es ist "nur" eine Shell, aber sie erleichtert das Programmieren und bietet eine komfortable Schnittstelle zum .NET-Universum.

Denken Sie auch daran, dass PowerShell Windows XP, Windows Server 2003 oder höher erfordert, was je nach Ihrer IT-Infrastruktur ein Problem darstellen kann.

Aktualisierung:

Ich hatte keine Ahnung, was für eine philosophische Debatte meine Antwort auslösen würde.

Ich habe meine Antwort im Zusammenhang mit der Frage gegeben: Vergleichen Sie PowerShell mit Cygwin, Perl und Bash.

PowerShell ist eine Shell, da sie keinen syntaktischen Unterschied zwischen integrierten Befehlen, Commandlets, Benutzerfunktionen und externen Befehlen (.exe, .bat, .cmd) macht. Lediglich das Aufrufen von .NET-Methoden unterscheidet sich durch das Hinzufügen eines Namespaces oder eines Objekts im Aufruf.

Die Programmierbarkeit ergibt sich aus dem .NET-Framework und nicht aus einer spezifischen PowerShell-"Sprache".

Ich würde sagen, dass ich PowerShell für eine "Skriptsprache" halte, sobald Bugzilla o MediaWiki sind als PowerShell-Skripte implementiert, die auf einem Webserver laufen ;)

Bis dahin, viel Spaß mit dem Vergleiche .

Answer 4

TL;DR - Ich hasse weder Windows noch PowerShell. Ich kann nur nicht tun irgendetwas in Windows oder in PowerShell.

---

Ich persönlich finde PowerShell nach wie vor bestenfalls unzureichend.

• Die Tabulatorvervollständigung von Verzeichnispfaden wird nicht zusammengesetzt, so dass der Benutzer nach jeder Namensvervollständigung ein Pfadseparator eingeben muss.

• Ich habe immer noch das Gefühl, dass Windows nicht einmal das Konzept eines Pfades kennt oder weiß, was ein Pfad ist, da es keinen Indikator für das Benutzerverzeichnis gibt. ~/ in Ermangelung von etwas @environment://somejibberish/%user_home%

• NTFS ist immer noch ein Chaos und wird es wohl immer sein. Viel Glück beim Navigieren.

• cmd-esque Schnittstelle, Der Dinosaurier cmd.exe ist in PowerShell noch sichtbar, Editar → Mark nach wie vor die einzige Möglichkeit, Informationen zu kopieren, und zwar nur in Form von rechteckigen Blöcken aus sichtbarem Terminalraum. und Editar → Mark ist nach wie vor die einzige Möglichkeit, Zeichenketten in das Terminal einzufügen.

• Es blau zu streichen, macht es nicht attraktiver. Ich habe aber nichts dagegen, wenn Microsoft-Entwickler einen eigenen Farbgeschmack haben.

• Windows wird immer in der linken oberen Ecke des Bildschirms geöffnet. Für jemanden, der vertikale Taskleisten verwendet, ist dies unglaublich ärgerlich, vor allem wenn man bedenkt, dass die Windows-Taskleiste die einzige Ecke des Fensters verdeckt, die Zugriff auf die Kopieren/Einfügen-Funktionalität bietet.

Zu den in Windows enthaltenen Tools kann ich nicht viel sagen. Da es eine ganze Reihe von quelloffenen, frei lizenzierten CLI-Tools gibt, mit denen PowerShell meines Wissens nach ausgeliefert wird, ist keines von ihnen eine völlige Enttäuschung.

• PowerShells wget benötigt scheinbar unvergleichbare Argumente zu GNU wget. Danke, Hoffnungsschimmer portabel-unbrauchbar.
• PowerShell POSIX ist nicht Bash-kompatibel, insbesondere die && Operator wird nicht behandelt, so dass die einfachste bedingte Befehlsfolge nicht möglich ist.

Ich weiß nicht, Mann; ich habe es versucht, das habe ich wirklich; ich versuche es immer noch, in der Hoffnung, dass es beim nächsten Mal, wenn ich es öffne, weniger nutzlos sein wird. Ich kann nichts in PowerShell tun, und ich kann kaum etwas mit einem echten Projekt tun, um GNU-Tools auf Windows zu bringen.

MySysGit gibt mir den Dinosaurier cmd.exe-Eingabeaufforderung mit ein paar GNU-Tools, und es ist immer noch sehr underwhelming, aber endlich Pfadvervollständigung funktioniert. Und der Git-Befehl wird in Git Bash ausgeführt.

Mintty für MySysGit bietet eine Cygwin-Schnittstelle für die MySysGit-Umgebung, die das Kopieren und Einfügen zu einem Kinderspiel macht (auswählen und kopieren (Maus)), Shift + Ins zum Einfügen, wie modern...). Allerdings, Dinge wie git push sind in Mintty kaputt.

Ich will nicht schimpfen, aber ich sehe immer noch große Probleme mit der Benutzerfreundlichkeit der Kommandozeile unter Windows, selbst mit Tools wie Cygwin.

---

P.S.: Nur weil etwas kann in PowerShell erledigt werden kann, macht es nicht verwendbar . Die Benutzerfreundlichkeit geht über die Fähigkeiten hinaus und ist das, worauf ich mich konzentriere, wenn ich versuche, ein Produkt als Verbraucher zu nutzen.

Answer 5

Da mich meine jüngsten Experimente in die Tiefen von PowerShell und .NET-Aufrufen geführt haben, muss ich sagen, dass PowerShell kann Cygwin und Unix-Shell ersetzen.

Bei Perl bin ich mir nicht sicher, aber da sowohl PowerShell als auch Perl als Programmiersprachen Turing-komplett sind, würde ich auch Perl durch diese Sprache ersetzen.

Eine Sache, die PowerShell Cygwin und der gewöhnlichen Bash unter *nix voraus hat, ist die Fähigkeit, DLL-Aufrufe im Sandkasten durchzuführen und das Betriebssystem über direkte API-Aufrufe, WMI-Methoden und sogar COM-Objekte zu manipulieren. Wie wäre es, den Internet Explorer per Code zu starten und dann mit dem angezeigten Dokument zu tun, was Sie wollen, und so effektiv ein Back-End für einen Webserver zu emulieren?

Wie wäre es, Daten von SQL-Servern und anderen Datenanbietern zu sammeln, sie zu parsen und als CSV, E-Mail-Nachrichten, Text und eigentlich jede Art von existierenden und nicht existierenden Dateiformaten zu exportieren? (Mit den richtigen Fähigkeiten zur Erstellung einer gültigen Datei aus den erhaltenen Daten, natürlich, aber CSV sind leicht verfügbar).

Und es gibt eine zusätzliche Sicherheit durch signierte Cmdlets und Skripte, Gruppenrichtlinien und Ausführungsrichtlinien, die verhindern, dass bösartiger Code auf Ihrem System ausgeführt wird, selbst wenn Sie sie als Administrator ausführen.

Welche Befehle implementiert sind - die Antwort von Richard listet sie auf und die Fähigkeit von PowerShell, ihre Funktionalität bereits zu emulieren.

Ob PowerShell stark genug ist, um einen Wechsel zu rechtfertigen, ist eher eine Frage der persönlichen Vorlieben. Da jedoch immer mehr Windows-Dienste PowerShell-Cmdlets zu ihrer Steuerung bereitstellen, wird die Nichtverwendung von PowerShell bei diesen Diensten als Hindernis angesehen. (Hyper-V-Server ist der wichtigste Dienst dieser Art, und er bietet auch die Möglichkeit, mehr mit PowerShell-Cmdlets als mit der grafischen Benutzeroberfläche zu tun!)

Wahrscheinlich kommt diese Antwort fünf Jahre zu spät, aber wenn jemand Verwaltungsaufgaben oder allgemeine Skripterstellung unter Windows durchführt, sollte er auf jeden Fall versuchen, die PowerShell für seine Zwecke zu nutzen.