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

Ich überlege, ob ich PowerShell lernen oder einfach bei Cygwin / Perl-Skripten / Unix-Shell-Skripten usw. bleiben soll.

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

Unix-Skripte sind so leistungsfähig, dass PowerShell nahe genug kommt, um eine Umstellung zu rechtfertigen?

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

• grep
• Sortieren
• uniq
• Perl (Wie nahe kommt PowerShell den Funktionen von Perl?)
• AWK
• sed
• Datei (der Befehl, der Dateiinformationen gibt)
• usw.

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 von ihnen erwarten, sind Sie ein glücklicher Kerl 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 eine gesunde Portion Respekt für diese Community.)

Was ich fand war, dass dies nicht wirklich viel half. Der Grund dafür ist, dass AWK / grep / sed nicht gegen COM , WMI , ADSI , die Registrierung, den Zertifikatspeicher usw. usw. funktioniert .

Mit anderen Worten, UNIX ist ein ganzes Ökosystem, das sich selbst um Textdateien dreht. Als solche sind Textverarbeitungswerkzeuge effektiv Verwaltungswerkzeuge. Windows ist ein völlig anderes Ökosystem, das sich um APIs und Objekte dreht. Deshalb haben wir PowerShell erfunden.

Ich denke, Sie werden feststellen, dass es viele Fälle 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 nicht alles oder nichts. In PowerShell können Sie Ihre Unix-Tools aufrufen (und deren Textverarbeitung oder die Textverarbeitung von PowerShell verwenden). Sie können PowerShell auch über Ihre Unix-Tools aufrufen und Text abrufen.

Auch hier - hier gibt es keine Religion - liegt unser Fokus darauf, Ihnen die Werkzeuge zu geben, die Sie benötigen, um erfolgreich zu sein. Deshalb sind wir so begeistert von Feedback. 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 es erreichen.

Ehrlich gesagt graben wir uns aus einem 30-jährigen Loch heraus, also wird es eine Weile dauern. Wenn Sie jedoch die Beta von Windows Server 2008 / R2 und / oder die Betas unserer Serverprodukte erwerben, werden Sie schockiert sein, wie schnell sich diese Lücke füllt.

In Bezug auf die Nutzung hatten wir bisher> 3,5 Millionen Downloads. Dies schließt nicht die Personen ein, die es in Windows Server 2008 verwenden, da es als optionale Komponente enthalten ist und keinen Download benötigt.

V2 wird in allen Windows-Versionen ausgeliefert. Es ist standardmäßig für alle Editionen aktiviert, außer für den Serverkern, bei dem es sich um eine optionale Komponente handelt. Kurz nach dem Versand von Windows 7 / Windows Server 2008 R2 stellen wir V2 auf allen Plattformen, Windows XP und höher, zur Verfügung. Mit anderen Worten - Ihre Investition in das Lernen wird auf eine sehr große Anzahl von Maschinen / Umgebungen anwendbar sein.

Ein letzter Kommentar. Wenn Sie anfangen, PowerShell zu lernen, werden Sie ziemlich glücklich sein. Ein Großteil des Designs ist stark von unseren Unix-Hintergründen beeinflusst. Obwohl wir uns stark voneinander unterscheiden, werden Sie es sehr schnell lernen (nachdem Sie darüber nachgedacht haben, dass es kein Unix ist :-)).

Wir wissen, dass die Menschen nur ein sehr begrenztes Budget für das Lernen haben - deshalb legen wir großen Wert auf Konsistenz. Sie werden etwas lernen und es dann immer und immer wieder verwenden.

Experiment! Genießen! Engagieren!

grep

Select-StringCmdlet und -matchOperator arbeiten mit regulären Ausdrücken. Sie können auch die Regex-Unterstützung von .NET direkt nutzen, um erweiterte Funktionen zu erhalten.

Sortieren

Sort-Objectist mächtiger (als ich mich erinnere * nix's sort). Ermöglichen der mehrstufigen Sortierung nach beliebigen Ausdrücken. Hier hilft die Wartung des zugrunde liegenden Typs durch PowerShell. Beispielsweise wird eine DateTimeEigenschaft als sortiert, DateTimeohne dass die Formatierung in ein sortierbares Format sichergestellt werden muss.

uniq

Select-Object -Unique

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

In Bezug auf Perls Breite domänenspezifischer Support-Bibliotheken: (noch) nicht in der Nähe.

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

AWK

Es ist lange genug her, seit ich AWK verwendet habe (muss> 18 Jahre sein, da ich später nur Perl verwendet habe), kann also nicht wirklich kommentieren.

sed

[Siehe oben]

Datei (der Befehl, der Dateiinformationen gibt)

Die Stärke von PowerShell ist hier nicht so sehr das, was es mit Dateisystemobjekten tun kann (und es erhält hier vollständige Informationen, dirRückgaben FileInfooder FolderInfoObjekte, je nach Bedarf), sondern das gesamte Anbietermodell.

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

PowerShell ist definitiv der richtige Weg unter Windows. 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 erweitern.

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 es ist insbesondere einfacher, die Daten weiter zu verarbeiten. Sie ermöglichen nicht nur einen umfassenderen Zugriff auf die gesamte TFS-Client-API, als dies in einem der beiden Team Explorer von TF.exe der Fall ist.

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

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

Angesichts der Tatsache, dass meine Arbeit zunehmend in heterogenen Umgebungen stattfindet, 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 eine Ware als eine monopolisierte ist, 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 Sie jedoch sehen, dass Ihre Zukunft von All-that-is-Redmond dominiert wird, entscheiden Sie sich für PowerShell.

Ich habe ein bisschen PowerShell für die Skriptautomatisierung verwendet. Während es sehr schön ist, dass die Umgebung viel mehr durchdacht zu sein scheint als Unix-Shells, ist die Verwendung von Objekten anstelle von Textströmen in der Praxis viel umständlicher 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 ist sicherlich besser als die Alternativen, wenn es darum geht, Dinge zu erledigen.

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, aber Dienstprogramme, die schwer zu vergleichen sind, aber Sie können fast alles in PowerShell tun.

Ich habe erst vor kurzem 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, habe ich einen Unix-Hintergrund und versuche ständig, meine Interaktionserfahrung unter Windows zu "Unix-fy". Es ist gelinde gesagt frustrierend.

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

Ich denke, der Schlüssel ist die 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 Textdateien. Windows hingegen war 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 wurde als GUI gestartet, und Verwaltungsfunktionen haben sich erst seit kurzem von der ausschließlichen GUI-basierten Funktion entfernt. Wir können davon ausgehen, dass die Unix-Erfahrung in der Befehlszeile angesichts des erheblichen Vorsprungs bei PowerShell umfangreicher und ausgereifter wird, und meine Erfahrung entspricht dieser. Nach meiner Erfahrung:

  • Die Unix-Verwaltungserfahrung ist darauf ausgerichtet, die Arbeit mit nur wenigen Tastenanschlägen zu vereinfachen. 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, die einen großen Beitrag zur Umgehung des ziemlich ausführlichen Verb-Nomen- Standards leisten , aber das Kennenlernen dieser Aliase ist ein bisschen mühsam (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:

    iptablesBefehle sind oft langwierig und das Wiederholen mit geringfügigen Unterschieden wäre schmerzhaft, wenn nicht nur eine der vielen in Bash integrierten Funktionen der Verlaufsmanipulation vorhanden wäre. Fügen Sie daher eine iptables-Regel wie die folgende ein:

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

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

    was bedeutet "führen Sie den vorherigen Befehl aus, aber ersetzen Sie -1- durch -2-und 50mit 51.

  • Das Unix-Erlebnis ist für Touch-Typisten optimiert. man kann so ziemlich alles machen, ohne die "Heimat" -Position zu verlassen. Verwenden Sie beispielsweise in Bash die Emacs- Tastenkombinationen (ja, Bash unterstützt auch vi Bindungen), durch die Geschichte Radfahren erfolgt mit Ctrl-Pund Ctrl-Nwährend der Bewegung zu Beginn und am Ende einer Zeile erfolgt mit Ctrl-Aund Ctrl-Ejeweils ... und es auf jedem Fall endet nicht dort. Probieren Sie selbst die einfachste Navigation in der PowerShell-Konsole aus, ohne sich von der Ausgangsposition zu entfernen, 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 auch keine umfassende Editor-Erfahrung. 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 wären sie auf so ziemlich jeder Unix-Variante.

• Die Windows-Kultur wird zumindest in Bezug auf die System-APIs weitgehend von den unterstützenden Frameworks ( COM und .NET) bestimmt , die beide stark strukturiert und objektbasiert sind. Andererseits erfolgte der Zugriff auf Unix-APIs traditionell über eine Dateischnittstelle ( /devund /proc) oder (nicht objektorientierte) Bibliotheksaufrufe im C-Stil. Es ist daher keine Überraschung, dass die Skripterfahrungen mit den jeweiligen Betriebssystemparadigmen übereinstimmen. PowerShell ist von Natur aus strukturiert (alles ist ein Objekt) und dateibasiert auf Bash - and -Friends. Die strukturierte API, die einem PowerShell-Programmierer zur Verfügung steht, ist umfangreich (entspricht im Wesentlichen der Größe der vorhandenen Standard- COM- und .NET-Schnittstellen).

Kurz gesagt, obwohl die Skriptfunktionen von PowerShell wohl leistungsfähiger sind als die von Bash (insbesondere wenn Sie die Verfügbarkeit von .NET BCL berücksichtigen ), ist die interaktive Erfahrung erheblich schwächer, insbesondere wenn Sie von einer vollständig tastaturgesteuerten Version aus arbeiten , konsolenbasierte Perspektive (wie viele Unix-Köpfe).

Ich bin keineswegs ein sehr erfahrener PowerShell-Benutzer, aber das kleine bisschen davon, dem ich ausgesetzt war, hat mich sehr beeindruckt. Sie können die integrierten Cmdlets miteinander verketten, um fast alles zu tun, was Sie an einer Unix-Eingabeaufforderung tun können. Außerdem gibt es einige zusätzliche Vorteile für den Export in CSV, HTML-Tabellen und für detailliertere Systemadministrationstypen .

Und wenn Sie wirklich so etwas wie sed brauchten , gibt es immer UnixUtils 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.

Im Wesentlichen sage ich, dass es sich lohnt, es zu lernen, wenn die Nur-Windows-Funktion kein Problem darstellt.

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

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

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

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

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

Wie wäre es, Daten von SQL-Servern und anderen Datenanbietern zu sammeln, zu analysieren und als CSV, E-Mail-Nachrichten, Text und tatsächlich alle vorhandenen und nicht vorhandenen Dateiformate zu exportieren? (Natürlich mit den richtigen Fähigkeiten zum Erstellen einer gültigen Datei aus empfangenen Daten, aber CSV ist leicht verfügbar).

Darüber hinaus steht eine zusätzliche Sicherheit über signierte Cmdlets und Skripts, Gruppenrichtlinien und Ausführungsrichtlinien zur Verfügung, mit denen verhindert wird, dass bösartiger Code auf Ihrem System ausgeführt wird, selbst wenn Sie sie als Administrator ausführen.

Informationen darüber, 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 eine Umstellung zu rechtfertigen - dies ist eher eine Frage der persönlichen Präferenz. Da jedoch immer mehr Windows-Dienste PowerShell-Cmdlets zur Steuerung bereitstellen, wird die Nichtverwendung von PowerShell mit diesen vorhandenen Diensten als Hindernis angesehen. (Der Hyper-V-Server ist der primäre derartige Dienst und bietet auch die Möglichkeit, mit PowerShell-Cmdlets mehr zu tun als mit der GUI!)

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

Beachten Sie beim Vergleichen 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, genau wie Sie es von cmd.exe oder Cygwin aus tun. Das tut es nicht neu zu implementieren , um die spezifizierten Funktionen, und es ist sicherlich nicht vergleichbar mit Perl.

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

Beachten Sie auch, dass für PowerShell Windows XP, Windows Server 2003 oder höher erforderlich ist, was je nach 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 gepostet: 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) macht. Nur das Aufrufen von .NET-Methoden unterscheidet sich durch Hinzufügen eines Namespace oder eines Objekts zum Aufruf.

Die Programmierbarkeit basiert auf dem .NET-Framework und nicht auf etwas, das für die PowerShell-Sprache spezifisch ist.

Ich würde sagen, ich glaube, PowerShell ist eine "Skriptsprache", sobald Bugzilla oder MediaWiki als PowerShell-Skripte implementiert sind, die auf einem Webserver ausgeführt werden;)

Bis dahin genießen Sie die Vergleiche .

Die Cmdlets in PowerShell sind sehr schön und funktionieren zuverlässig. Ihre Objektorientierung gefällt mir sehr gut, da ich ein Java / C # -Entwickler bin, aber es ist überhaupt kein vollständiger Satz. Da es objektorientiert ist, wird ein Großteil der Textstromreife des POSIX-Tool-Sets ( awkund) verpasstsed um nur einige zu nennen) .

Die beste Antwort auf das Dilemma, OO-Techniken zu lieben und die Reife der POSIX-Tools zu lieben, ist, beide zu verwenden! Ein großartiger Aspekt von PowerShell ist, dass es hervorragende Arbeit leistet, Objekte an Standard-Streams weiterzuleiten. PowerShell verwendet standardmäßig eine Objektpipeline, um seine Objekte zu transportieren. Dies sind nicht die Standard-Streams (Standard-Out, Standard-Fehler und Standard-In). Wenn PowerShell die Ausgabe an einen Standardprozess ohne Objektpipeline übergeben muss, werden die Objekte zunächst in einen Textstrom konvertiert. Da dies so gut funktioniert, ist PowerShell ein ausgezeichneter Ort, um POSIX-Tools zu hosten!

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

Installationsanleitung für GnuWin32

Laden Sie die exe herunter und führen Sie sie aus (sie stammt von der SourceForge-Site ). Zeigen Sie sie auf ein geeignetes Verzeichnis (das ich verwenden werde C:\bin). Dort wird ein GetGnuWin32Verzeichnis erstellt, in dem Sie ausgeführt werden download.bat. Anschließend wird install.bat(ohne Parameter) ein C:\bin\GetGnuWin32\gnuwin32\binVerzeichnis angezeigt, das der nützlichste Ordner ist, der jemals auf einem Windows-Computer vorhanden war. Fügen Sie dieses Verzeichnis Ihrem Pfad hinzu, und Sie können loslegen.

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

Ich persönlich finde PowerShell im besten Fall immer noch ü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 eines Pfads oder eines Pfades hat, ohne dass ein zugänglicher Benutzer-Home-Indikator ~/fehlt@environment://somejibberish/%user_home%

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

• cmd-artige Schnittstelle, Der Dinosaurier cmd.exe ist noch sichtbar in Powershell, Bearbeiten → Mark sind immer noch die einzige Möglichkeit , Informationen zu kopieren, und das Kopieren nur in Form von rechteckigen Blöcken des sichtbaren Klemmenraumes. und Bearbeiten → Markieren ist immer noch die einzige Möglichkeit, Zeichenfolgen in das Terminal einzufügen.

• Wenn Sie es blau streichen, wird es nicht attraktiver. Ich habe nichts dagegen, dass Microsoft-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 Kopier- / Einfügefunktionen bietet.

Ich kann aufgrund der Tools, die Windows enthält, nicht viel sagen. Da es eine ganze Reihe von Open-Source-CLI-Tools mit freier Lizenz gibt und PowerShell meines Wissens mit ausgeliefert wird, ist keines davon eine völlige Enttäuschung.

• PowerShell's verwendet wgetscheinbar unvergleichliche Argumente für GNU wget. Danke, Hoffnungsschimmer tragbar nutzlos.
• PowerShell POSIX ist nicht Bash-kompatibel, insbesondere wird der &&Bediener nicht behandelt, sodass der einfachste bedingte Befehl keine Rolle spielt.

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

MySysGit gibt mir die Eingabeaufforderung dinosaur cmd.exe mit ein paar GNU-Tools, und es ist immer noch sehr überwältigend, aber endlich 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 macht das Kopieren und Einfügen zu einer Sache (zum Kopieren auswählen (Maus), Shift+ Inszum Einfügen, wie modern ...). Dinge wiegit push in Mintty kaputt.

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

PS: Nur weil in PowerShell etwas getan werden kann , ist es nicht verwendbar . Benutzerfreundlichkeit ist tiefer als Fähigkeit und ist das, worauf ich mich konzentriere, wenn ich versuche, ein Produkt als Verbraucher zu verwenden.

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.

In Ihrer Notlage sind Sie möglicherweise besser dran mit einer Skriptsprache, die andere hinter sich lassen könnten, Perl, wie Sie es erwähnt haben, oder anderen wie Ruby oder Python.

Ich denke, vieles 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 nie weitergeben kann - also versuche ich, nichts zu Revolutionäres zu tun.

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 die 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). Beispiele finden Sie unter https://bitbucket.org/jbianchi/powershell/wiki/Home

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

Das Hauptwerkzeug, das ich verwende, ist ssh.exe, jedoch innerhalb einer PowerShell-Sitzung.

Es funktioniert großartig.

Ich fand, dass die PowerShell-Programmierung die Mühe nicht wert ist.

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

Es scheint, als müssten Sie bei vielen Funktionen die Windows-Verwaltungsoberfläche abfragen und SQL-ähnliche Befehle ausgeben, um die benötigten Informationen zu erhalten.

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

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

Nachdem ich ein paar Stunden mit Scripting.FileSystemObjectund WScript.Shellund "SELECT * FROM Win32_ShortcutFile WHERE Drive = '" & drive & "' AND Path = '" & searchFolder & "'" herumgespielt hatte, gab ich es endlich auf und entschied mich für den Windows Explorer- Suchbefehl und mach es einfach manuell. Es gibt wahrscheinlich eine Möglichkeit, das zu tun, was ich wollte, aber ich habe nichts Offensichtliches gesehen und alle Beispiele auf der MSDN-Website waren so trivial, dass sie wertlos waren.

EDIT Heh, natürlich habe ich mich, sobald ich das geschrieben habe, noch ein bisschen umgesehen und festgestellt, was mir gefehlt hat: Die -recurseOption zum Befehl remove-item ist fehlerhaft (wird angezeigt, wenn Sie verwenden get-help remove-item -detailed).

Ich hatte versucht "remove-item -filter '* .xyz' -recurse" und es funktionierte nicht, also gab ich es auf.

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

Sie können auch versuchen, Bash-Skripte unter Windows mit BashWin unter https://github.com/skanga/BashWin auszuführen .

PowerShell ist sehr leistungsfähig und leistungsfähiger als die Standardintegrationen der Unix-Shells (jedoch nur, weil es einen Großteil der Funktionen enthält, die normalerweise für Unterprogramme bereitgestellt werden). Denken Sie auch daran, dass Sie Applets in jeder .NET-Sprache schreiben können, einschließlich IronPython , IronRuby , PerlNet usw., oder Sie können einfach Ihre Cygwin-Befehle von PowerShell aus aufrufen und alle zusätzlichen Funktionen ignorieren. Dies funktioniert ähnlich wie Bash, KornShell , oder Wasauchimmer...