it-swarm.com.de

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

Ich überlege, ob ich PowerShell lernen soll oder mich einfach an Cygwin /Perl-Skripte/Unix-Shell-Skripte usw. halten soll.

Der Vorteil von PowerShell ist, dass die Skripte von Teammitgliedern, die Cygwin nicht haben, einfacher verwendet werden können. Ich weiß jedoch nicht, ob ich wirklich so viele Allzweck-Skripte schreiben würde oder ob die Leute sie überhaupt benutzen würden.

Unix-Scripting ist so leistungsfähig, kommt PowerShell der Umstellung nahe?

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

  • grep
  • sortieren
  • uniq
  • Perl (wie nahe kommt PowerShell den Möglichkeiten von Perl?)
  • AWK
  • sed
  • file (der Befehl, der Dateiinformationen liefert)
  • usw.
379
Andy White

Werkzeuge sind nur Werkzeuge.
Sie helfen oder nicht.
Du brauchst Hilfe oder nicht.

Wenn Sie wissen, dass Unix und diese Tools unter Windows genau das tun, was Sie benötigen, sind Sie ein fröhlicher Mensch und müssen PowerShell nicht lernen (es sei denn, Sie möchten es erkunden).

Meine ursprüngliche Absicht war es, eine Reihe von Unix-Tools in Windows aufzunehmen und damit fertig zu werden (einige von uns im Team haben einen tiefen Unix-Hintergrund und respektieren diese Community voll und ganz.) Was ich fand, war, dass dies nicht der Fall war wirklich viel helfen. Der Grund dafür ist, dass awk/grep/sed nicht gegen COM, WMI, ADSI, die Registrierung, den Zertifizierungsspeicher usw. funktioniert. Mit anderen Worten, UNIX ist ein vollständiges Ökosystem, das sich selbst um Textdateien dreht. Textverarbeitungswerkzeuge sind als solche effektiv Verwaltungswerkzeuge. Windows ist ein völlig anderes Ökosystem, das auf APIs und Objekte abgestimmt ist. Deshalb haben wir PowerShell erfunden.

Was ich denke, Sie werden feststellen, dass es viele Gelegenheiten geben wird, in denen die Textverarbeitung unter Windows nicht das bringt, was Sie wollen. An diesem Punkt möchten Sie PowerShell abholen. HINWEIS - Es ist kein Alles-oder-Nichts-Geschäft. In PowerShell können Sie Ihre Unix-Tools aufrufen (und ihren Textprozess oder die Textverarbeitung von PowerShell verwenden). Sie können PowerShell auch von Ihren Unix-Tools aus aufrufen und Text abrufen.

Auch hier - hier gibt es keine Religion - konzentrieren wir uns darauf, Ihnen die Werkzeuge zu geben, die Sie benötigen, um erfolgreich zu sein. Deshalb sind wir von Feedback so begeistert. Lassen Sie uns wissen, wo wir auf den Job fallen oder wo Sie kein Werkzeug haben, das Sie benötigen, und wir werden es auf die Liste setzen und darauf zugreifen. Ehrlich gesagt graben wir uns aus einem 30-jährigen Loch heraus, also wird es eine Weile dauern. Wenn Sie jedoch die Betaversion von Windows Server 2008 /R2 und/oder die Betaversionen unserer Serverprodukte herunterladen, werden Sie schockiert sein, wie schnell diese Lücke gefüllt wird.

In Bezug auf die Nutzung hatten wir bisher> 3,5 Millionen Downloads. Dies schließt die Benutzer in Windows Server 2008 nicht ein, da es als optionale Komponente enthalten ist und keinen Download erfordert. V2 wird in allen Windows-Versionen ausgeliefert. Es ist standardmäßig für alle Editionen aktiviert, mit Ausnahme von Server Core, bei dem es sich um eine optionale Komponente handelt. Kurz nach der Auslieferung von Windows 7/Windows Server 2008 R2 stellen wir V2 auf allen Plattformen XP und höher) zur Verfügung. Mit anderen Worten: Ihre Investition in das Lernen wird sich auf eine sehr große Anzahl von Anwendern auswirken Maschinen/Umgebungen.

Ein letzter Kommentar. Wenn/wenn Sie anfangen, PowerShell zu lernen, werden Sie ziemlich glücklich sein. Ein Großteil des Designs wird stark von unseren Unix-Hintergründen beeinflusst, so dass Sie es, obwohl wir uns sehr unterscheiden, sehr schnell verstehen werden (nachdem Sie darüber hinweggekommen sind, dass es sich nicht um Unix handelt :-)). Wir wissen, dass die Menschen ein sehr begrenztes Budget für das Lernen haben - deshalb legen wir großen Wert auf Beständigkeit. Sie werden etwas lernen und es dann immer und immer wieder anwenden.

Experiment! Genießen! Engagieren!

775

grep

Select-String Cmdlet und -match Operator arbeiten mit regulären Ausdrücken. Sie können auch direkt die Unterstützung für reguläre Ausdrücke in .NET nutzen, um erweiterte Funktionen zu erhalten.

sortieren

Sort-Object ist mächtiger (als ich mich an * nix's sort erinnere). Ermöglichen der mehrstufigen Sortierung nach beliebigen Ausdrücken. Hier hilft die Wartung des zugrunde liegenden Typs durch PowerShell. z.B. Eine DateTime -Eigenschaft wird als DateTime sortiert, ohne dass die Formatierung in ein sortierbares Format erfolgen muss.

uniq

Select-Object -Unique

Perl (wie nahe kommt PowerShell den Perl-Funktionen?)

In Bezug auf Perls Breite domänenspezifischer Supportbibliotheken: (noch) nicht annähernd.

Für die allgemeine Programmierung ist PowerShell sicherlich zusammenhängender und konsistenter und einfacher zu erweitern. Die eine Lücke für das Text-Munging entspricht Perls .. Operator.

AWK

Es ist schon lange genug her, dass ich AWK verwendet habe (muss> 18 Jahre sein, da ich später nur Perl verwendet habe), also kann ich nichts dazu sagen.

sed

[Siehe oben]

file (der Befehl, der Dateiinformationen liefert)

Die Stärke von PowerShell besteht darin, dass es nicht so viel mit Dateisystemobjekten zu tun hat (und dass es hier vollständige Informationen erhält und dirFileInfo - oder FolderInfo -Objekte zurückgibt) ist das ganze Anbietermodell.

Sie können die Registrierung, den Zertifikatspeicher, SQL Server, den RSS-Cache von Internet Explorer usw. als Objektbereich behandeln, der mit denselben Cmdlets wie das Dateisystem navigiert werden kann.


Unter Windows ist PowerShell definitiv der richtige Weg. Microsoft hat es zu einem Teil seiner Anforderungen für zukünftige Nicht-Heimprodukte gemacht. Daher umfangreiche Unterstützung in Exchange, Unterstützung in SQL Server. Dies wird sich nur ausweiten.

Ein aktuelles Beispiel hierfür sind die TFS PowerToys. Viele TFS-Client-Vorgänge werden ausgeführt, ohne dass tf.exe jedes Mal gestartet werden muss (was eine neue TFS-Serververbindung usw. erfordert), und die Daten können dann wesentlich einfacher weiterverarbeitet werden. Darüber hinaus können Sie detaillierter auf die gesamte TFS-Client-API zugreifen, als dies in Team Explorer von TF.exe der Fall ist.

120
Richard

Als jemand, dessen Karriere sich von 1997 bis 2010 auf die Windows-Unternehmensentwicklung konzentrierte, wäre PowerShell aus all den guten Gründen, die zuvor genannt wurden, die naheliegende Antwort (z. B. ist es Teil der Unternehmensstrategie von Microsoft; es lässt sich gut mit Windows/COM/.NET integrieren) Die Verwendung von Objekten anstelle von Dateien liefert ein "reichhaltigeres" Codierungsmodell. Aus diesem Grund habe ich PowerShell in den letzten zwei Jahren verwendet und beworben, mit der ausdrücklichen Überzeugung, dass ich das "Word of Bill" befolgt habe.

Als Pragmatiker bin ich mir jedoch nicht mehr sicher, ob PowerShell eine so gute Antwort ist. Obwohl es sich um ein hervorragendes Windows-Tool handelt und einen dringend erforderlichen Schritt zum Ausfüllen der historischen Lücke in der Windows-Befehlszeile darstellt, scheint es immer wahrscheinlicher, dass Microsoft einen massiven Kampf vor sich hat, um das Betriebssystem beizubehalten wichtig für das Unternehmen der Zukunft.

Angesichts der Tatsache, dass meine Arbeit zunehmend in heterogenen Umgebungen ausgeführt wird, finde ich es im Moment viel nützlicher, Bash-Skripte zu verwenden, da sie nicht nur unter Linux, Solaris und Mac OS X funktionieren, sondern auch - mit dem Hilfe von Cygwin - unter Windows.

Wenn Sie sich also der Überzeugung anschließen, dass die Zukunft des Betriebssystems eher als Ware denn als Monopol betrachtet wird, erscheint es sinnvoll, sich für eine agile Strategie für Entwicklungstools zu entscheiden, die sich nach Möglichkeit von proprietären Tools fernhält. Wenn Ihre Zukunft jedoch von All-That-Is-Redmond dominiert wird, entscheiden Sie sich für PowerShell.

57
Ubiguchi

Ich habe ein bisschen PowerShell für die Skriptautomatisierung verwendet. Während es sehr schön ist, dass die Umgebung viel mehr als nur für Unix-Shells gedacht zu sein scheint, ist die Verwendung von Objekten anstelle von Textströmen in der Praxis viel klobiger und viele der Unix-Funktionen, die in den letzten 30 entwickelt wurden Jahre fehlen noch.

Cygwin ist immer noch meine bevorzugte Skriptumgebung für Windows-Hosts. Es übertrifft sicherlich die Alternativen, wenn es darum geht, Dinge zu erledigen.

32
Daishiman

Hier gibt es viele großartige Antworten, und hier ist meine Meinung. PowerShell ist bereit, wenn Sie ... Beispiele:

grep = " Select-String -Pattern "

sort = "Sort-Object"

uniq = " Get-Unique "

file = " Get-Item "

cat = " Get-Content "

Perl/AWK/Sed sind keine Befehle, sondern nur schwer zu vergleichende Dienstprogramme. In PowerShell können Sie jedoch fast alles ausführen.

15
Vic

Ich habe erst kürzlich angefangen, mich ernsthaft mit PowerShell zu beschäftigen. Obwohl ich in den letzten sieben Jahren in einer fast ausschließlich Windows-basierten Umgebung gearbeitet habe, komme ich aus einem Unix-Umfeld und bin ständig bemüht, meine Interaktionserfahrung unter Windows zu "verfeinern". Es ist gelinde gesagt frustrierend.

Es ist nur fair, PowerShell mit etwas wie Bash , tcsh oder zsh zu vergleichen, da Dienstprogramme wie grep, - sed, awk, find usw. sind streng genommen nicht Teil der Shell; Sie werden jedoch immer Teil einer Unix-Umgebung sein. Allerdings hat ein PowerShell-Befehl wie Select-String eine sehr ähnliche Funktion wie grep und ist, die als Kernmodul in PowerShell gebündelt sind. .. so können die Linien etwas verschwommen sein.

Ich denke, der Schlüssel ist Kultur und die Tatsache, dass die jeweiligen Toolsets ihre jeweiligen Kulturen verkörpern:

  • Unix ist eine dateibasierte (im Allgemeinen nicht Unicode) textbasierte Kultur. Konfigurationsdateien sind fast ausschließlich Text Dateien. Andererseits war Windows in Bezug auf Konfigurationsformate immer viel strukturierter - 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 die Entwicklungsschnittstelle) war traditionell die Befehlszeile und das virtuelle Terminal. Windows startete als GUI, und Verwaltungsfunktionen sind erst seit kurzem nicht mehr nur exklusiv GUI-basiert. Wir können davon ausgehen, dass die Unix-Erfahrung auf der Kommandozeile aufgrund des erheblichen Vorsprungs auf PowerShell umfangreicher und ausgereifter ist, und meine Erfahrung entspricht dieser. Nach meiner Erfahrung:

    • Die Unix-Verwaltungserfahrung zielt darauf ab, die Dinge mit einem Minimum an Tastenanschlägen einfach zu machen. Dies ist wahrscheinlich auf die historische Situation zurückzuführen, dass ein Server über eine langsame 9600-Baud-DFÜ-Verbindung verwaltet werden muss. Jetzt hat PowerShell Aliase, mit denen man den ziemlich ausführlichen Verb-Noun -Standard weitestgehend umgehen kann. Das Kennenlernen dieser Aliase ist jedoch ein wenig schmerzhaft (jeder weiß etwas Besseres als: alias | where {$_.ResolvedCommandName -eq "<command>"}?).

      Ein Beispiel für die reichhaltige Art und Weise, wie die Geschichte manipuliert werden kann:

      iptables -Befehle sind oft langwierig und das Wiederholen mit geringfügigen Unterschieden wäre ein Schmerz, wenn nicht nur eine von vielen netten Funktionen der in Bash integrierten Verlaufsmanipulation vorhanden wäre, also Einfügen Eine Iptables-Regel wie die folgende:

      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 der Ausgabe von:

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

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

    • Das Unix-Erlebnis ist für Schreibkräfte optimiert. man kann so ziemlich alles machen, ohne die "Heimat" -Position zu verlassen. Beispiel: In Bash wird bei Verwendung der Emacs -Tasten (ja, Bash unterstützt auch vi -Bindungen) das Durchlaufen des Verlaufs mit ausgeführt Ctrl-P und Ctrl-N Wenn Sie sich an den Anfang und das Ende einer Zeile bewegen, verwenden Sie Ctrl-A und Ctrl-E jeweils ... und es endet definitiv nicht dort. Probieren Sie die einfachste Navigation in der PowerShell-Konsole aus, ohne die Ausgangsposition zu verlassen, und Sie haben Probleme.

    • Einfache Dinge wie vielseitiges Paging (a la less ) unter Unix scheinen in PowerShell nicht sofort verfügbar zu sein, was ein wenig frustrierend ist, und es gibt keine umfangreiche Editorerfahrung entweder. Natürlich kann man immer Tools von Drittanbietern herunterladen, die diese Lücken füllen, aber es wäre sicher schön, wenn diese Dinge nur "da" wären, als ob sie auf so ziemlich jeder Unix-Variante wären.
  • Zumindest in Bezug auf die System-APIs wird die Windows-Kultur hauptsächlich von den unterstützenden Frameworks bestimmt, nämlich COM und . NET Beide sind stark strukturiert und objektbasiert. Auf der anderen Seite erfolgte der Zugriff auf Unix-APIs traditionell über eine Dateischnittstelle (/dev und /proc) oder (nicht objektorientierte) C-Bibliotheksaufrufe. Es ist daher nicht verwunderlich, dass die Skripterfahrungen mit den jeweiligen Betriebssystemparadigmen übereinstimmen. PowerShell ist von Natur aus strukturiert (alles ist ein Objekt) und Bash - und-Freunde dateibasiert. Die strukturierte API, die einem PowerShell-Programmierer zur Verfügung steht, ist sehr umfangreich (entspricht im Wesentlichen der Größe der vorhandenen Standard COM - und .NET-Schnittstellen).

Kurz gesagt, obwohl die Skriptfunktionen von PowerShell wahrscheinlich leistungsfähiger sind als Bash (insbesondere, wenn Sie die Verfügbarkeit von .NET berücksichtigen BCL =), das interaktiv Erlebnis ist bedeutend schwächer, insbesondere wenn Sie es aus einer vollständig tastaturgesteuerten, konsolenbasierten Perspektive betrachten (so wie es viele Unix-Köpfe sind).

13
Eric Smith

Ich bin keineswegs ein sehr erfahrener PowerShell-Benutzer, aber das bisschen, dem ich ausgesetzt war, hat mich sehr beeindruckt. Sie können die integrierten Cmdlets miteinander verketten, um so gut wie alles zu tun, was Sie an einer Unix-Eingabeaufforderung tun können. Außerdem können Sie Dinge wie den Export in CSV, HTML-Tabellen und tiefere sys-admin-Typen ausführen Arbeitsplätze. Und wenn Sie wirklich etwas wie sed brauchten, gibt es immer nixUtils oder GnuWin32 , die Sie ziemlich einfach in Powershell integrieren können.

Als langjähriger Unix-Benutzer hatte ich jedoch einige Probleme, mich an das Befehlsbenennungsschema zu gewöhnen, und ich hätte sicherlich mehr davon profitiert, wenn ich mehr über .NET gewusst hätte.

Ich sage also im Wesentlichen, dass es sich lohnt, es zu lernen, wenn die reine Windows-Funktionalität kein Problem darstellt.

8
yalestar

Wenn Sie Shell-Scripting mögen, werden Sie PowerShell lieben!

Beginnen Sie mit Eine Führung durch die Microsoft Command Shell (Ars Technica).

6
Nick

Beachten Sie beim Vergleich von PowerShell mit der Kombination Cygwin/Perl/Shell, dass PowerShell nur den "Shell" -Teil dieser Kombination darstellt.

Sie können jedoch jeden Befehl von PowerShell aus aufrufen, genauso wie Sie dies von cmd.exe oder Cygwin aus tun. Es führt keine Neuimplementierung der angegebenen Funktionen durch und ist sicherlich nicht mit Perl vergleichbar.

Es ist "nur" eine Shell, erleichtert aber die Programmierung und bietet eine komfortable Schnittstelle zum .Net-Universum.

Beachten Sie auch, dass PowerShell WinXP, Srv2003 oder höher benötigt, was je nach Ihrer IT-Infrastruktur ein Problem darstellen kann.

Aktualisieren:

Ich hatte keine Ahnung, welche Art von philosophischer Debatte meine Antwort auslösen würde.

Ich habe meine Antwort im Zusammenhang mit der Frage veröffentlicht: Vergleichen Sie PowerShell mit Cygwin und Perl und bash.

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

Die Programmierbarkeit basiert auf dem .Net-Framework und nicht auf der PowerShell-Sprache.

Ich würde sagen, ich glaube, PowerShell ist eine "Skriptsprache", sobald Bugzilla oder MediaWiki als PowerShell-Skripte auf einem Webserver implementiert sind.

Bis dahin genießen Sie die Vergleiche .

6
devio

Als meine jüngsten Experimente mich in die Tiefe der PowerShell- und .NET-Aufrufe führten, muss ich sagen, dass PowerShell kann Cygwin und Unix Shell ersetzt.

Ich bin mir bei Perl nicht sicher, aber da sowohl PowerShell als auch Perl als Programmiersprachen vollständig sind, gebe ich dies auch als Ja zum Ersetzen von Perl aus.

Eine Sache, die PowerShell über Cygwin und Bash unter * nix verfügt, ist die Fähigkeit, Sandbox-Aufrufe DLL auszuführen und das Betriebssystem über direkte API-Aufrufe, WMI-Methoden und sogar COM-Objekte zu manipulieren. Wie wäre es, wenn Sie Internet Explorer über Code starten und dann mit dem angezeigten Dokument das tun, was Sie wollen, um effektiv ein Back-End für einen Webserver zu emulieren?

Wie wäre es mit dem Sammeln von Daten von SQL-Servern und anderen Datenanbietern, dem Parsen und Exportieren als CSV, E-Mail-Nachrichten, Text und tatsächlich jeder Art von vorhandenen und nicht vorhandenen Dateiformaten? (Mit den richtigen Fähigkeiten zum Erstellen einer gültigen Datei aus den empfangenen Daten, aber CSV sind leicht verfügbar).

Durch signierte Cmdlets und Skripts, Gruppenrichtlinien und Ausführungsrichtlinien ist eine zusätzliche Sicherheit verfügbar, die verhindert, dass böswilliger Code auf Ihrem System ausgeführt wird, selbst wenn Sie ihn als Administrator ausführen.

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

Die Frage, ob PowerShell eine Umstellung zu rechtfertigen vermag, ist eher eine persönliche Angelegenheit. Da jedoch immer mehr Windows-Dienste PowerShell-Cmdlets zur Steuerung dieser Dienste bereitstellen, wird die Nichtverwendung von PowerShell mit diesen Diensten als Hindernis angesehen. (Hyper-V-Server ist der primäre Dienst dieser Art und bietet außerdem die Möglichkeit, mehr mit PowerShell-Cmdlets als mit GUI zu tun!)

Wahrscheinlich ist diese Antwort fünf Jahre zu spät. Wenn jedoch jemand administrative Aufgaben oder allgemeine Skripts für verschiedene Dinge unter Windows ausführt, sollte er auf jeden Fall versuchen, PowerShell für seine Zwecke zu nutzen.

6
Vesper

TL; DR - Ich hasse Windows oder PowerShell nicht. Ich kann einfach nichts in Windows oder PowerShell tun .


Ich persönlich finde PowerShell immer noch bestenfalls überwältigend.

  • die Tab-Vervollständigung von Verzeichnispfaden wird nicht zusammengesetzt, sodass der Benutzer nach jeder Namensvervollständigung ein Pfadtrennzeichen eingeben muss.
  • Ich habe immer noch das Gefühl, dass Windows nicht einmal das Konzept von Pfad oder was für ein Pfad ist, mit keiner zugänglichen Benutzer-Home-Anzeige ~/, Die von einigen @environment://somejibberish/%user_home% Abweicht.
  • NTFS ist immer noch ein Chaos und wird es anscheinend immer sein. Viel Glück beim Navigieren.

  • cmd-esque-Schnittstelle, Die Datei dinosaur cmd.exe ist in PowerShell weiterhin sichtbar. edit->mark ist weiterhin die einzige Möglichkeit, Informationen zu kopieren, und sie wird nur in Form von rechteckigen Blöcken mit sichtbarem Terminalbereich kopiert. und edit->paste ist immer noch die einzige Möglichkeit, Zeichenfolgen in das Terminal einzufügen.

  • Blau zu malen macht es nicht attraktiver. Ich habe nichts dagegen, dass MS-Entwickler einen Geschmack in Farbe haben.

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

Aufgrund der Tools, die Windows enthält, kann ich nicht viel sagen. Die Tatsache, dass es eine ganze Reihe von Open-Source-CLI-Tools mit freier Lizenz gibt und PowerShell meines Wissens mit keinem von ihnen geliefert wird, ist eine völlige Enttäuschung.

  • PowerShell wget nimmt scheinbar unvergleichliche Argumente an GNU wget, dank Hoffnungsschimmer tragbar-nutzlos.
  • PowerShell POSIX ist nicht Bash-kompatibel, insbesondere wird der Operator && Nicht behandelt, sodass der einfachste bedingte Befehl nach nichts ausgeführt werden kann.

Ich kenne keinen Mann. Ich habe es ausprobiert, das habe ich wirklich getan. Ich versuche immer noch, es zu versuchen, in der Hoffnung, dass es beim nächsten Öffnen weniger nutzlos wird. Ich kann in PowerShell nichts tun und mit einem echten Projekt kaum etwas anfangen, um GNU Tools auf Windows zu bringen.

MySysGit gibt mir die Eingabeaufforderung dinosaur cmd.exe mit ein paar GNU Werkzeugen, und es ist immer noch sehr überwältigend, aber letztendlich funktioniert die Pfadvervollständigung. Und der Git-Befehl wird in Git Bash ausgeführt.

Mintty for MySysGit bietet die Cygwin-Oberfläche über die Umgebung von mysysgit und ermöglicht das Kopieren und Einfügen (zum Kopieren auswählen (Maus), shift+ins kleben, wie modern ...). In Mintty sind jedoch Dinge wie git Push Fehlerhaft.

Ich will nicht schimpfen, aber ich sehe immer noch große Probleme mit der Befehlszeilen-Bedienbarkeit unter Windows, selbst wenn Tools wie Cygwin vorhanden sind.


PS: Nur weil etwas in PowerShell ausgeführt werden kann , kann es nicht verwendet werden . Benutzerfreundlichkeit ist tiefer als Fähigkeit und ist das, worauf ich mich neige, wenn ich versuche, ein Produkt als Verbraucher zu nutzen.

4
ThorSummoner

Die Cmdlets in PowerShell sind sehr gut und funktionieren zuverlässig. Ihre Objektorientierung gefällt mir sehr, da ich ein Java/C # -Entwickler bin, aber es ist überhaupt kein vollständiges Set. Da es objektorientiert ist, wird ein Großteil der Textstromreife des POSIX-Werkzeugsatzes (awk und sed um nur einige zu nennen).

Die beste Antwort, die ich auf das Dilemma des Liebens von OO=) Techniken und des Liebens der Reife in den POSIX-Werkzeugen gefunden habe, ist, beides zu verwenden! Standardmäßig verwendet PowerShell eine Objekt-Pipeline, um die Objekte zu transportieren. Dies sind nicht die Standard-Streams (Standardausgang, Standardfehler und Standardeingang). Wenn PowerShell die Ausgabe an einen Standardprozess übergeben muss, der dies nicht tut Wenn Sie über eine Objekt-Pipeline verfügen, werden die Objekte zunächst in einen Text-Stream konvertiert. Da dies so gut funktioniert, eignet sich PowerShell hervorragend für Host POSIX-Tools.

Das beste POSIX-Toolset ist GnuWin32 . Die Installation dauert länger als 5 Sekunden, aber die Mühe lohnt sich. Soweit ich das beurteilen kann, ändert sie Ihr System (Registrierung, c:\windows\* - Ordner usw.) nur, wenn Sie Dateien in das kopieren von Ihnen angegebene Verzeichnisse. Dies ist besonders praktisch, da viele Benutzer gleichzeitig auf die Tools zugreifen können, wenn Sie sie in einem freigegebenen Verzeichnis ablegen.

GnuWin32 Installationsanleitung

Laden Sie die exe herunter und führen Sie sie aus (sie stammt von der SourceForge-Site ), auf die sie verweist in ein geeignetes Verzeichnis (ich verwende C:\bin). Es wird dort ein GetGnuWin32 - Verzeichnis erstellt, in dem Sie download.bat Und dann install.bat (Ohne Parameter) ausführen. Danach wird ein C:\bin\GetGnuWin32\gnuwin32\bin - Verzeichnis erstellt Dies ist der nützlichste Ordner, der jemals auf einem Windows-Computer existiert hat. Fügen Sie dieses Verzeichnis Ihrem Pfad hinzu, und Sie können loslegen.

4

Warum nicht beide verwenden? Rufen Sie PowerShell-Skripte in Cygwin wie alle anderen interpretierten Skripte wie Perl usw. auf.

Ich mache das genug, dass ich https://bitbucket.org/jbianchi/powershell geschrieben habe, damit ein Bash-Wrapper powershell.exe in Cygwin aufruft. Es kann als Shebang als erste Zeile eines Powershell.exe .ps1-Skripts verwendet werden (da PowerShell auch "#" als Kommentar verwendet). Siehe https://bitbucket.org/jbianchi/powershell/wiki/Home für Beispiele

2
johnnyB

Ich habe nicht gesehen, dass die PowerShell wirklich gestartet ist, zumindest noch nicht. Es lohnt sich also möglicherweise nicht, es zu lernen, es sei denn, die anderen in Ihrem Team wissen es bereits.

Für Ihre Situation ist es vielleicht besser, wenn Sie eine Skriptsprache verwenden, die andere hinter sich lassen könnten, Perl, wie Sie es erwähnt haben, oder andere, wie Ruby oder Python.

Ich denke, viel hängt davon ab, was Sie tun müssen. Persönlich habe ich Python für meine eigenen persönlichen Skripte verwendet, aber ich weiß, wenn ich anfange, etwas zu schreiben, das ich niemals weitergeben kann - also versuche ich, auch nichts zu tun Revolutionär.

2
greg

In ein paar Zeilen sind Cygwin und PowerShell verschiedene Tools. Wenn Sie Cygwin installiert haben, können Sie die ausführbaren Dateien von Cygwin innerhalb einer PowerShell-Sitzung ausführen. Ich habe mich so an PowerShell gewöhnt, dass ich jetzt nicht mehr grep, sort, awk usw. verwende. Es gibt in PowerShell ziemlich viele integrierte Alternativen, und wenn nicht, finden Sie dort ein Cmdlet.

Das Hauptwerkzeug, das ich benutze, ist ssh.exe, jedoch in einer PowerShell-Sitzung.

Es funktioniert super.

1
yaxzone

PowerShell ist sehr leistungsfähig, leistungsfähiger als die Standard-Built-Ins der Unix-Shells (allerdings nur, weil es einen Großteil der Funktionen enthält, die normalerweise für Unterprogramme vorgesehen sind). Bedenken Sie auch, dass Sie Applets in einer beliebigen .NET-Sprache schreiben können, einschließlich IronPython, IronRuby, PerlNet usw., oder Sie können Ihre Cygwin-Befehle einfach von PowerShell aus aufrufen und alle zusätzlichen Funktionen ignorieren. oder Wasauchimmer...

0

Die PowerShell-Programmierung hat sich für mich nicht gelohnt.

Ich habe mehrere Jahre Erfahrung mit Shell-Skripten unter Unix, aber ich fand es enorm schwierig, mit PowerShell viel zu tun.

Anscheinend müssen Sie für viele Funktionen die Windows-Verwaltungsoberfläche abfragen und SQL-ähnliche Befehle absetzen, um die benötigten Informationen abzurufen.

Zum Beispiel wollte ich ein Skript schreiben, um alle Dateien mit einem bestimmten Suffix aus einem Verzeichnisbaum zu entfernen. Unter Unix wäre dies ein einfaches .. .

find . -name \*.xyz -exec rm {} \;

Nach ein paar Stunden mit Scripting.FileSystemObject Und WScript.Shell Und der Ausgabe von "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'", Schließlich gab ich auf und entschied mich für den Windows Explorer-Befehl Search und mache es einfach manuell. Es gibt wahrscheinlich eine Möglichkeit, das zu tun, was ich wollte, aber ich sah nichts Offensichtliches und alle Beispiele auf der MSDN-Site waren so trivial, dass sie wertlos waren.

[~ # ~] edit [~ # ~] Heh, natürlich, sobald ich das geschrieben habe, habe ich ein bisschen mehr herumgesucht und herausgefunden, was ich war missing: Die Option -recurse für den Befehl remove-item ist fehlerhaft (wird angezeigt, wenn Sie get-help remove-item -detailed verwenden).

Ich habe versucht "remove-item-filter '* .xyz' -recurse" und es hat nicht funktioniert, also habe ich es aufgegeben.

Es stellt sich heraus, dass Sie get-childitem -filter '*.xyz' -recurse | remove-item Verwenden müssen

0
TMN