Dies macht die Verwendung von rm , ls usw. zum Kotzen, da kein Globbing durchgeführt wird:

> touch blah.tmp
> ls *.tmp                                                                                                          
ls: *.tmp: No such file or directory
> Get-ChildItem *.tmp

    Directory: /Users/andrew/src/PowerShell


Mode                LastWriteTime         Length Name                                                                                 
----                -------------         ------ ----                                                                                 
------           5/3/16   8:39 PM              0 blah.tmp

> rm *.tmp
rm: *.tmp: No such file or directory
> Remove-Item *.tmp
> Get-ChildItem *.tmp

Blah.

Die Usability-Synchronisierung stimmt im Allgemeinen darin überein, dass die interaktive Erfahrung ohne die Aliase nicht funktioniert. Wir sind uns nicht einig, welche Alternativen Benutzern angeboten werden sollten, die standardmäßig die nativen Binärdateien verwenden möchten. Einige Optionen, die veröffentlicht wurden, sind:

• Eine Umgebungsvariable zum Deaktivieren aller Aliase, die mit * nix-Binärdateien kollidieren
• Ein einzelnes Zeichen (wie ^ ), das automatisch in den nativen Pfad fällt
• Sagen Sie den Leuten, dass sie bash -c (viele sagten, dies seien zu viele Zeichen, um verwendet werden zu können)
• Sagen Sie den Leuten, dass sie den vollständigen Weg bereitstellen müssen (diese Erfahrung funktioniert technisch bereits, ist aber sehr schlecht).
• Nebenvorschlag: Nutzen Sie das "Hinweis-Subsystem", um den Leuten mitzuteilen, dass sie möglicherweise den nativen Befehl verwenden wollten, wenn sie Parametersätze verwenden, die Muster mit den nativen * nix-Binärdateien abgleichen. Dies kann immer noch nur funktionieren, wenn der Befehl fehlschlägt ( rm -e würde beispielsweise nicht fehlschlagen).

Ich denke, das ist etwas, was wir eher früher als später herausfinden wollen, also habe ich es auf v0.5.0 verschoben. Meiner Meinung nach ist eine PowerShell-Einstellung zum Wechseln des Modus der beste erste Schritt.

@andschwa und Standard wäre ....?

@vors meine _personale_ Meinung: die PowerShell-Aliase aktiviert; weil Sie PowerShell ausführen.

Schließlich möchten wir ohnehin eine Anleitung zum erstmaligen Starten "Erste Schritte" für PowerShell und geben an, dass dies eine verfügbare Einstellung ist.

@ BrucePay irgendwelche Updates dazu?

Die heutige Usability-Synchronisierung wiederholte, dass die Aliase wieder verwendet werden sollten. (Das Weiterleiten an sort ist ein weiterer Datenpunkt für eine völlig kaputte PS-Erfahrung.)

Lassen Sie Bruce als Beauftragten, um den besten Weg vorwärts mit den oben genannten Abschwächungen zu bestimmen. @andschwa : Wir brauchen wahrscheinlich jemanden, der die Arbeit

Ich hatte gerade ein Gespräch mit @jpsnover und er ist sich sehr keine Aliase zurücksetzen . Wir sollten die Posteingangsdatei aliases.ps1 erstellen und die Dot-Sourcing-Datei fördern.

Es ist wahrscheinlich erwähnenswert, dass ls in Bash normalerweise nicht einfach ls , sondern ein Alias ​​mit einigen Standardargumenten, wobei die Ausgabe möglicherweise am bemerkenswertesten ist, wenn sie mit Farbe ausgegeben wird.

PowerShell-Aliase funktionieren überhaupt nicht wie Aliase unter Linux, daher müssten wir entweder ls als Funktion definieren oder unsere Aliase so verbessern, dass sie eher wie Bash-Aliase funktionieren.

Es könnte sich auch lohnen, einige Zeit damit zu verbringen, Module in der Galerie zu analysieren, um festzustellen, wie viele nicht funktionieren würden, wenn die Aliase entfernt würden - sort ist besonders besorgniserregend.

Die Aliase sind heute nicht vorhanden, und wir sollten sicherstellen, dass wir für den 17. August eine gesunde Diskussion über die Vor- und Nachteile der Alias-Situationen führen, an denen sich die Menschen beteiligen können.

Sieht so aus, als hätten wir eine Geschichte, die das Problem abschließt.

Mein 2p dazu - eine neue PowerShell-Einstellungsvariable ähnlich der in PSv3 eingeführten $ PSModuleAutoLoadingPreference würde es dem Endbenutzer ermöglichen, dies in ihren Profilen zu steuern (könnte auch ein einfaches Beispiel zusammenstellen, das einige Befehle zeigt, die mit und ohne PS ausgeführt werden Aliase als gut

Suggestiver Name $ PSUsePowerShellAliases und wenn er nicht explizit auf true gesetzt ist (innerhalb des Profils oder interaktiv), werden die Standard-Aliase * nix verwendet.
Ich glaube, dass dies wahrscheinlich auch eine bessere Benutzeroberfläche für diejenigen bieten würde, die sich jetzt entscheiden könnten, das Wasser mit PowerShell zu testen, was vorher nicht möglich gewesen wäre, da es nicht das wegnimmt, was sie wissen, sondern denjenigen von uns, die den PS-Weg kennen, die Möglichkeit gibt um dies auch zu tun.

nicht wegnehmen, was sie wissen

Absolut. Wenn es einen Kompromiss geben muss, sollte dies zugunsten von Linux Bash-Benutzern erfolgen, dh potenziellen neuen PowerShell-Benutzern. Die vorhandenen PowerShell-Gläubigen können ihre * nix-Aliase leicht genug oder noch besser neu erstellen und sich von diesen Aliasen entwöhnen.

Jetzt, da wir PowerShell unter Linux haben, würde ich gerne sehen, dass die integrierten * nix-Aliase aus allen Betriebssystemversionen von PowerShell Core entfernt werden - sofern dies noch nicht geschehen ist. Das würde integrierte Aliase hinterlassen, die mit den integrierten PowerShell-Befehlen übereinstimmen, und nicht versuchen, Sie zu "täuschen".

Ich bin ein Fan für das Entfernen der gängigen Aliase von ps unter Linux - ich bin kein Fan davon, dies unter Windows zu "reparieren", wie Keith vorschlägt. Mein Argument dafür ist, dass wenn Sie einen Linux-Benutzer für PowerShell gewinnen und dieser sich entscheidet, es auch unter Windows zu versuchen, er nicht die gemeinsamen Aliase hat.

Könnte dies zu PSReadline hinzugefügt werden, der Fähigkeit, Linux-Aliase zu aktivieren oder nicht? Für mich ist es einfach, meinen Code zu reparieren, der Kurznamen für Funktionen verwendet. Trotzdem werde ich immer zuerst LS eingeben und erwarten, dass es wie der PowerShell LS-Alias ​​für Get-ChildItem funktioniert.

Sie können dieses Problem gerne verwenden, um Ihre Meinung zum Verhalten von PowerShell zu äußern.

Ich denke, was @kilasuit , @rkeithhill und @ 1RedOne angesprochen haben, scheint die beste Lösung zu sein - lassen Sie es unter Linux und MacOS standardmäßig deaktivieren, aber machen Sie es uns gleichzeitig einfach, es in der Konsole oder in zu aktivieren unsere Skripte.

Bestehende Skripte können aktualisiert werden, um nach dieser Variablen zu suchen und die Option sofort zu deaktivieren oder zu aktivieren. Es ist besser, eine Menge Code zu durchsuchen, um nach Kurznamen zu suchen, die sich nicht wie erwartet verhalten.

Off-Topic - nicht nur begeistert davon, dass PowerShell auf anderen Plattformen verfügbar ist! 😄

In Bezug auf PSReadLine sollte @lzybkr @juneb gibt, die

Ich könnte sicherlich ein Beispiel für PSReadline veröffentlichen, um bestimmte Aliase durch das PowerShell-Cmdlet zu ersetzen. Es würde auf diesem Beispiel basieren: https://github.com/lzybkr/PSReadLine/blob/master/PSReadLine/SamplePSReadlineProfile.ps1#L354

Trotzdem denke ich nicht, dass es eine echte Lösung ist.

Das größte Problem in meinem Kopf ist der Konflikt zwischen Skriptportabilität und Vertrautheit. Wir haben Hinweise gegeben, dass Skripte keine Aliase verwenden sollten, aber es ist immer noch gängige Praxis. Einige Aliase sind möglicherweise problematischer als andere, z. B. wird sort ls in Skripten möglicherweise mehr als ps oder ls .

Wir haben sicherlich einige Optionen besprochen, z. B. die Bereitstellung eines Moduls, das Sie gerade importieren, um diese Aliase zurückzugewinnen. Wir haben uns aber noch nicht entschieden und hoffen auf weitere Rückmeldungen.

Das Ersetzen von PowerShell-Befehlen durch native ausführbare Dateien ohne Globbing-Unterstützung hilft definitiv nicht dabei, Bash-Leute davon zu überzeugen, PowerShell zu verwenden.

Also, Leute, vielleicht ist es besser, native ausführbare Dateien einfach um Globbing-Unterstützung zu erweitern? Das wird alle Probleme lösen und PowerShell für alle nutzbarer machen, oder? Link # 954.

Als * nix-Benutzer, der kaum Fenster berührt hat, möchte ich eine starke Stimme dafür abgeben, dass die Aliase beibehalten werden. Viele Jahre Muskelgedächtnis haben mich gelehrt, ls , rm usw. Ich möchte mein Muskelgedächtnis nicht neu lernen müssen (und es dann immer wieder neu lernen müssen, wenn ich in Bash lande), um die native Powershell-Erfahrung zu erhalten.

Korrigieren Sie mich, wenn ich hier falsch liege, aber ist das anders für dir unter Windows? In PS unter Windows ist dir nicht dir.exe . Es ist Get-ChildItem . Warum sollte ls unter * nix /bin/ls statt Get-ChildItem ?

@Gaelan Ich habe verstanden, aber bitte beachten Sie, dass es in Windows keine dir.exe -Datei gibt. dir ist ein interner Befehl des Befehlsprozessors cmd , ähnlich dem eingebauten Befehl bash . Vielleicht ist dies der (eine) Grund, weil PowerShell nicht dafür ausgelegt war, diesen externen Befehl dir.exe direkt aufzurufen.

@Gaelan , @ForNeVeR : Während cmd-integrierte Funktionen niemals zusammenstoßen, weil sie nicht als Programme vorhanden sind, gibt es PowerShell-Aliase, die selbst unter Windows mit nativen ausführbaren Dateien in Konflikt stehen.

Im Allgemeinen glaube ich nicht, dass es eine sichere Möglichkeit gibt, Aliase beizubehalten und Dinge nicht zu beschädigen, da theoretisch jeder einzelne Alias ​​(außer vielleicht denjenigen, die im Dateisystem nicht existieren können, wie ? ) eine native ausführbare Datei beschatten könnte, die kann dann nicht mehr aufgerufen werden (zumindest nicht über seinen Basisnamen).

PS> gal|?{gcm "$_.exe" -ea 0}

CommandType     Name
-----------     ----
Alias           fc -> Format-Custom
Alias           sc -> Set-Content
Alias           sort -> Sort-Object
Alias           where -> Where-Object
Alias           write -> Write-Output

Die einzige sichere Route wäre also, überhaupt keine Aliase zu haben, was den Zweck irgendwie zunichte macht. Und ohne Zweifel sind die Standard-Aliase vor allem praktisch. Ich habe hier eigentlich keine gute Antwort.

Ich persönlich würde es vorziehen, wenn die Aliase belassen würden. Sie dienen im Allgemeinen dazu, die Navigation und die allgemeine Shell-Nutzung schneller und komfortabler zu gestalten. Wenn Sie sie entfernen, wird die Erfahrung mit PowerShell beeinträchtigt.

Ich unterstütze die Idee, möglicherweise eine Möglichkeit hinzuzufügen, um anzuzeigen, dass Sie stattdessen die integrierte Linux-Binärdatei aufrufen. Vielleicht sogar als Profilpräferenz?

Wenn Sie sich den Verlauf hier ansehen, habe ich vorgeschlagen, was aus UX-Sicht meiner Meinung nach die beste Lösung für Aliase ist, die einem entsprechenden Nicht-Windows-Befehl zugeordnet sind

Dies ist ein langjähriges PowerShell-Problem. Ich beschwere mich, dass es keinen Befehl gibt, der mit dir von cmd oder sogar mit ls . Die Antwort lautet jedes Mal "aber es gibt einen Alias!".

Aliase sind und waren keine Lösung für dieses Problem. Die Aliase dir und ls bieten nicht die Funktionalität, die dir und ls bieten. Gleiches gilt für die Aliase wget und curl .

Die gesamte Herangehensweise an die Aliase muss überdacht werden, und das bedeutet, dass Änderungen gebrochen werden.

Warum können systemdefinierte Aliase nicht nur Bürger zweiter Klasse für Binärdateien in PATH sein?

Ich würde sagen, entfernen Sie alle * nix-Aliase unter Linux, OS X-Builds, bis Sie herausgefunden haben, was zu tun ist.

Bearbeiten: Vielen Dank für die Klarstellung, dass dies bereits geschehen ist, entschuldigen Sie die Unterbrechung.

@okket die schon gemacht wurden. Wir diskutieren, ob etwas geändert werden muss.

Mir scheint, wir sollten einfach alle Aliase in Dateien einfügen, die Benutzer in ihren Profilen verwenden können, und dann ein systemspezifisches Standardprofil bereitstellen ...

bash-aliases.ps1
dos-aliases.ps1
initial-aliases.ps1

Wenn nichts anderes, erinnert das die Leute daran, dass nicht jeder die gleichen Kurznamen hat.

Man darf nicht vergessen (@sleepypikachu) , dass Powershell - Aliase nicht _do_ nichts außer Umbenennungs das Kommando und überschreiben , um Befehlsauflösung. Die alias -Funktionalität von Bash erfordert _Funktionen_ in PowerShell.

@Gaelan Ihr Muskelgedächtnis bringt Sie dazu, den Alias ​​zu verwenden, aber wären Sie frustriert darüber, dass die Parameter und das Verhalten nicht mit dem eigentlichen Befehl funktionieren?

Das ist das eigentliche Problem hier und @DrPizza ist

Hier gibt es also wirklich drei verwandte Themen:

1. Nicht alle Parameter sind mit einem Alias ​​versehen
2. Nicht alle nativen Parameter oder Verhaltensweisen sind in PowerShell CmdLet zugeordnet.
3. Benötigen Sie eine Möglichkeit, einen nativen Befehl auszuführen, wenn ein Alias ​​vorhanden ist

Ich denke nicht, dass # 1 ein schlechtes Problem ist und die Dinge noch schlimmer machen würde, wenn sie einen Alias ​​hätten. Dir -recurse ist sowieso ein besser lesbarer Parameter als dir / s. Mit dem Cross-Plat werden Skripte inkonsistent, wenn versucht wird, von Windows auf Linux und umgekehrt zu wechseln.

2 und # 3 sind am wichtigsten. Ich habe Curl nie verwendet, aber ich weiß, dass ich mit Invoke-WebRequest auf Einschränkungen gestoßen bin, von denen ich erwarten würde, dass Curl dies kann. (Erinnern Sie sich nicht an Kopf).

Kurzfristig benötigen Sie sowohl eine Konfigurationsoption als auch eine Möglichkeit, den nativen Befehl aufzurufen, wenn der Alias ​​aktiviert ist.

Standardmäßig lassen Sie es aktiviert. Dies ist PowerShell ... unter Linux. Es sollte sich wie PowerShell verhalten, damit sie lernen können, welche CmdLets verwendet werden sollen. Mein Kollege mit Linux- und Perl-Hintergrund fand es viel einfacher, die Cmds herauszufinden, die er brauchte, um ein Skript zum Laufen zu bringen. Ich denke, es war grep, ls und man, der für ihn der Schlüssel war. Die Verwendung von man sollte ihnen helfen, herauszufinden, wie sie das cmd richtig verwenden können.

Fügen Sie den nativen Cmdlets langfristig eine Abdeckung hinzu, um alle Parameter und Funktionen nativer Befehle zu nutzen. Dies verbessert PowerShell für Windows und Linux, indem es uns leistungsfähigere Optionen bietet. Einige der Verhaltensweisen müssen wahrscheinlich in mehrere CmdLets konvertiert werden und Objekte und Pipelines verwenden, aber das ist eine großartige Sache! Wenn dies nicht der Fall wäre, worum geht es dann bei PowerShell?

Meine Meinung ist, so zu bleiben, wie es ist. Kein Alias ​​in PowerShell (außer select und etc., sie sind erforderlich), Alias ​​in Windows PowerShell.

Das Bereitstellen einer Option ist besser, aber es ist nicht unmöglich, alle Aliase als Optionen bereitzustellen.

IMHO mit ls Alias ​​zu dir macht Sinn, da ich Where-Object leicht verwenden könnte, um Dateien zu filtern. Ich bin seit Jahren ein Linux-Benutzer und die Eingabe von dir ist nicht so selbstverständlich wie die Verwendung von ls.

Es scheint mir, dass Konsistenz wichtig ist. Ich bin nicht dagegen, die Aliase von anderen Plattformen zu entfernen, aber eine Schnittstelle zu haben, die sich je nach Betriebssystem unterschiedlich verhält, stört mich. Einer der Hauptpunkte bei der Ausführung von PS unter * nix ist, dass es eine einzige Schnittstelle ist, um alles zu verwalten. Wenn die Aliase auf den neu unterstützten Plattformen aus PowerShell entfernt werden sollen, sollte meiner Meinung nach überlegt werden, ob sie auch unter Windows entfernt werden sollen.

Nein, ich unterstütze nachdrücklich, dass PS standardmäßig Aliase bereitstellt, aber die Realität darunter sollte genau die gleiche Funktionalität (und möglicherweise Parameterkompatibilität) wie die ursprünglichen nativen Binärdateien haben, mit Ausnahme der Unterstützung für die Eingabe.
PowerShell ohne Typen ist nutzlos.

Die Verwendung der zugrunde liegenden Systembinärdateien und die Übernahme der Unix-Tools-Philosophie fördern die Übernahme. Als Entwickler von Unix-Shops war ich angenehm überrascht, dass die normalen Unix-Binärdateien in dieser Implementierung etwas funktionierten. In Bezug auf das * Charakterproblem denke ich, dass die meisten Leute auf der * nix-Seite gerne ein Escape-Zeichen vor dem * verwenden würden, wenn sie * nix-Shell-Glob anzeigen, im Gegensatz zu dem, was sich derzeit in Powershell verhält. Wahrscheinlich wäre eine akzeptable Lösung für | Da eine Pipe, die ein Objekt anstelle eines Oktettstroms zwischen Dateien erzeugt, gegen veröffentlichte Standards verstößt und die Übernahme behindert. http://pubs.opengroup.org/onlinepubs/009695399/functions/pipe.html

@ be5invis Bitte beachten Sie: Niemand wird Typen aus PowerShell entfernen . entweder gci und Get-ChildItem bleiben in Windows PowerShell und Linux PowerShell gleich. Hier geht es nur darum, ob ein eingebauter Alias ​​wie ls -> Get-ChildItem unter Linux existieren sollte oder nicht. Ihre Skripte sollten sowieso nicht ls oder gci aufrufen, wenn Sie Get-ChildItem aufrufen möchten (da die Verwendung von Aliasen in Skripten nicht empfohlen wird und nie empfohlen wurde). ls und gci sind nur bequeme Aliase für die Befehlszeilennutzung, und es könnte den Linux-Benutzer verwirren, wenn ls plötzlich auf Get-ChildItem und nicht auf seinen Alias ​​ausgerichtet ist bevorzugter nativer Befehl; es wird ihn noch mehr verwirren, wenn er keine präzise Möglichkeit hat, diesen Befehl direkt aufzurufen.

Ich bin für verwendet Befehl, um Alias ​​auf Powershell zu aktivieren.
Behalten Sie alle Aliasnamen bei und verwerfen Sie sie langsam auf Windows Powershell.

Ich denke mit Befehl wie

Enable-Alias Unix
Enable-Alias dos

Das Aktivieren von Alias ​​hat folgende Vorteile

1. Es löst das Problem für Menschen, die native Locken verwenden möchten
2. Es rät davon ab, Alias ​​in Skripten zu verwenden (was die Lesbarkeit des Skripts beeinträchtigt).
3. Es ist auch super einfach für Leute, die diesen Alias ​​lieben, sie zu aktivieren
4. und es beeinträchtigt kaum die Leistung.

@ForNeVeR Ich benutze ls als gci ganzen Tag, weil es einen Buchstaben kürzer ist ...
Die Einführung dieser Änderung (Entfernen von Unix-y- und Dos-y-Aliasen) ist jedoch definitiv eine bahnbrechende Änderung (sie entspricht nicht curl ). Eine „perfekte“ Lösung könnte darin bestehen, diese Befehle für eine typisierte Erweiterung vorhandener Tools zu implementieren.
Für Skripte vielleicht ... eine using -Anweisung?

@ForNeVeR Ich denke, Sie haben @ be5invis missverstanden. Er ist ein starker Befürworter von Powershell. Ich denke, was er mit "Powershell ohne Typ ist nutzlos" meint, ist, dass Leute keine native Locke in Powershell verwenden sollten.

@ be5invis Auch ich denke, Ihre Vorstellung von der Kompatibilität von nativen Locken ist weitreichend. Die Powershell-Grammatik ist nicht mit der Standard-Unix-Grammatik kompatibel. Sie können beispielsweise rm -rf unter Unix ausführen, aber in Powershell müssen Sie rm -r -fo ausführen.
Daher werden Sie niemals die Parameterkompatibilität erreichen, egal was passiert.

@chantisnake Warum also nicht einen Parameter namens "rf" hinzufügen, der -recurse -force ?

@ be5invis Dies fr . Außerdem könnte -Recurse plötzlich nicht mehr auf -r gekürzt werden, sondern müsste stattdessen -re um nicht mit Ihrem vorgeschlagenen -rf -Parameter in Konflikt zu geraten.

Sie könnten dieselbe Frage von der anderen Seite stellen: Warum nicht beide Parameter separat angeben? Sie sind bereit, gegen die Prinzipien und Konventionen des PowerShell-Codes zu verstoßen, nur um so zu tun, als würden Sie immer noch mit denselben Unix-Tools arbeiten, auch wenn Sie dies nicht tun. Die GNU-Parameterkonventionen mit ihren kurzen und langen Namen sind jedoch kaum universell und viele etablierte Tools widersprechen ihnen, z. B. tar oder find . Sie sind jedoch nicht in der Lage, ihre Bug-Tracker zu ändern. Während ein Kernbestandteil von Unix immer darin bestand, dass es eine Milliarde verschiedener Hilfsprogramme gibt, die jeweils auf leicht unterschiedliche Weise funktionieren, ist es plötzlich so, dass es plötzlich ein weiteres gibt (zugegebenermaßen ein bisschen mehr und versucht, viele andere Hilfsprogramme in sich aufzunehmen) so beunruhigend und problematisch, dass es geändert werden muss? Das glaube ich nicht.

Denken Sie daran: Die Shell auf Ihrem Computer gehört Ihnen. So wie die Leute Alias rm bis rm -i für ihren eigenen Komfort verwenden, hindert Sie nichts daran, den Alias rm entfernen und eine Funktion zu haben, die Remove-Item Namen rm mit einem -rf -Parameter.

Der Versuch, PowerShell vollständig zu ändern, um jedes einzelne Unix-Tool vollständig zu replizieren, ist jedoch ziemlich falsch.

Die Funktionalität und Ausgabe von ls ist seit vielen Jahren gut definiert. Der Befehl ls gibt einen Oktettstrom in einem bekannten Format aus. Der Befehl ls gibt keine DirectoryInfo- und FileInfo-Objekte aus. Wenn ls etwas anderes ausgegeben wird, ist dies zumindest verwirrend und möglicherweise etwas trügerisch.

Wenn der Benutzer bereit ist, die Vorteile von Objekten in der Pipeline zu nutzen, lernt er Get-ChildItem und gci kennen. Wenn der Benutzer die Vorteile von Objekten in der Pipeline nicht nutzen oder damit umgehen möchte, ist es für den Benutzer möglicherweise besser, bash, ksh, csh, sh usw. zu verwenden.

Das Gleiche gilt für den Befehl DIR unter Windows.

Sei * nix * nix und mache Powershell so gut es geht.

@ Liturgist

Wenn der Benutzer bereit ist, die Vorteile von Objekten in der Pipeline zu nutzen, lernt er Get-ChildItem und gci kennen. Wenn der Benutzer die Vorteile von Objekten in der Pipeline nicht nutzen oder damit umgehen möchte, ist es für den Benutzer möglicherweise besser, bash, ksh, csh, sh usw. zu verwenden.

Dies widerspricht Ihrem Standpunkt. Wenn Benutzer Powershell verwenden, möchten sie wahrscheinlich Objekte in der Pipeline. Wir sollten dann keine grundlegenden Befehle neu lernen, um dies auszunutzen.

Stimmen Sie mit @Gaelan überein.
Wenn jemand keine Objekte möchte, kann er einfach zu bash oder zsh wechseln.
Sie möchten die Vorteile von Objekten nutzen, und durch das Aliasing von Dingen wie ls auf eine kompatible, aber typisierte Version erhalten sie genau das, was sie möchten.

@Gaelan und @ be5invis , ich verstehe den Wunsch, das Ausmaß der Änderungen zu begrenzen, die ein Benutzer ls bevor mein Gehirn ihnen überhaupt ein Signal sendet.

Das Problem ist, dass diese vorhandenen Grundbefehle keine Objekte erzeugen. Die tatsächlich vorzunehmende Änderung reicht nicht von ls bis gci . Die größere Änderung betrifft das Denken bei der Verarbeitung von Textzeilen und das Nachdenken über die Eigenschaften und die Methoden, die auf ein Objekt angewendet werden können.

Jeder Benutzer hat das Recht, beliebige Aliase zu erstellen. Ich würde zustimmen, dass es dem Benutzer leicht gemacht werden könnte, dies zu tun, indem $ Host (System.Management.Automation.Internal.Host.InternalHost) eine Methode und eine Eigenschaft hinzugefügt wird, um das Ersetzen nativer Befehle zu aktivieren oder zu deaktivieren. Ich habe andere gesehen, aber ist in Powershell ein GUI-Profilkonfigurationstool enthalten?

Wenn jemand keine Objekte möchte, kann er einfach zu bash oder zsh wechseln.

Warum kann PowerShell Menschen, die seit Jahren Bash verwenden und sich dann dazu entschließen, ihre Zehen in die PowerShell-Gewässer zu tauchen, keine "einfache Rampe" bieten? Lassen Sie sie mit dem beginnen, was sie wissen, und beginnen Sie mit der Einführung von PowerShell-Funktionen (z. B. objektemittierenden Befehlen und Objekten in der Pipeline), wenn sie sich mit PowerShell wohler fühlen.

Ich kann Ihnen nicht sagen, wie oft ich die Zeile "_PowerShell ist eine Shell . Sie kann Ihre bevorzugten nativen Dienstprogramme problemlos ausführen _" verwenden musste, um die Leute über die Vorstellung hinaus zu bringen, dass sie PowerShell nur mit diesen komisch klingenden Befehlen verwenden könnten und um sie dazu zu bringen, PowerShell tatsächlich auszuprobieren. PowerShell muss beliebte native Dienstprogramme so gut wie möglich respektieren und mit ihnen zusammenarbeiten. Das ist schließlich eine der Hauptaufgaben einer "Shell".

@rkeithhill Lassen Sie mich also klarstellen: Benutzer, die Powershell verwenden möchten, möchten Typen, oder? Ihre nativen Tools wie /bin/ls können jedoch nicht mit Typen kommunizieren. Wenn Sie zu einer typisierten Shell wechseln, jedoch ohne typisierte Utils, ist die Änderung bedeutungslos.

Daher möchten typische Unix-Benutzer möglicherweise den identischen Befehl eingeben, das eingegebene Ergebnis jedoch direkt abrufen. Es gibt also zwei Möglichkeiten:

1. Zweck eine typisierte IPC - Protokoll und sagen Linus ihre Werkzeuge zu aktualisieren - Nein, sie wont't, weil sie durch ihre ENEMY vorgesetzt wird, der bösen Lord, der Zerstörer der freien Welt! Sie werden uns "umarmen, ausdehnen und auslöschen"! oder...
2. Alias ls für ein eingebautes System mit kompatiblen Parametern.

Benutzer, die Powershell verwenden möchten, möchten Typen, oder?

Irgendwann werden sie es wahrscheinlich tun. Trotzdem arbeite ich mit einer Reihe von Entwicklern, die ich mit PowerShell begonnen habe, indem ich sie lediglich bei Verwendung mit Git und Posh-Git verkaufe (etwas, das CMD nicht bieten kann). Zu diesem Zeitpunkt leiten sie selten etwas weiter, aber ich erwarte, dass sie dort ankommen. Dieser Punkt ist, dass sich das Dienstprogramm git.exe unter PowerShell genauso verhält wie unter CMD. Einfacher Übergang.

Für mich ist ls (wie ps, grep, sed, awk, gcc, curl usw.) nur ein weiteres natives Dienstprogramm, das jede "Shell" ausführen kann. Wenn jemand bereit ist und den Befehl zum Ausgeben von Objekten zum Auflisten von Containerinhalten möchte, kann er Get-ChildItem oder dessen Alias gci . Wenn sie der Meinung sind, dass sie das native Dienstprogramm ls niemals verwenden werden, können sie in ihrem Profil einen Alias ls für Get-ChildItem erstellen.

Übrigens denke ich nicht, dass es machbar ist, Get-ChildItem Parameter mit ls kompatibel zu machen. Sie werden ziemlich schnell hängen bleiben, wenn bei PowerShell-Parametern nicht zwischen Groß- und Kleinschreibung unterschieden wird, z. B. -c / -C, -d / -D, -i / -I. Und PowerShell unterstützt keine Parameterkombination, z. B. ls -rt. Es ist eine Reichweite und verstößt gegen das Monad-Prinzip von PowerShell. Eine Aufgabe wie das Sortieren wird von einem separaten Cmdlet (Sort-Object) und nicht von Get-ChildItem selbst ausgeführt.

@rkeithhill Ich werde nicht dafür sorgen, dass Get-ChildItem mit ls kompatibel ist. Ich beabsichtige ein anderes Cmdlet, kann als vollständiger Name UnixCompatibles-ls werden und habe einen separaten Befehlsparser, der anstelle von PowerShell die GNU getopt-Variante akzeptiert.

@ be5invis Ist die einfachere Option zu diesem Zeitpunkt nicht eine separate Funktion, die ls ausführt , alle Argumente übergibt, die Ausgabe analysiert und daraus Objekte erstellt? Ein vollständig separater Befehlsparser (zusammen mit vollständig separaten Befehlsmetadaten, Formatierung für Get-Help , ...) ist etwas übertrieben (abgesehen davon, dass ein Großteil der internen Funktionen von PowerShell inkompatibel repliziert wird.

Hier wird es immer zwei getrennte Welten geben, eine native, eine getippte. PowerShell bedient bereits beide, indem native Programme und Cmdlets ausgeführt werden können. Ich persönlich sehe keinen Vorteil (nur ein gewaltiger Entwicklungsaufwand) darin, eine Ebene über nativen Befehlen hinzuzufügen, die ihre Parametermetadaten in PowerShell repliziert. Außerdem, was würden Sie mit tar oder find (und vielen anderen Programmen) tun, die AFAIK nicht an die GNU-Konventionen hält? Implementieren Sie noch einen anderen Befehlsparser zusammen mit Wrapper-Funktionen, um diese aufzurufen? Beachten Sie außerdem, dass die Argumente des nativen Programms in PowerShell analysiert werden müssen und nicht mit der Sprache in Konflikt stehen dürfen, damit ein Befehlsparser funktioniert. Etwas, das mit seltsamen Dingen wie [ schwierig sein könnte.

@ygra Es ist auch okay.

Benutzer, die Powershell verwenden möchten, möchten Typen, oder?

@ be5invis , vielleicht tritt hier ein bisschen Trennung auf. Nein, sie wollen keine Typen. Der Benutzer möchte seine Arbeit oder sein Spiel erledigen. Der Benutzer weiß, dass ls einen Textstrom erzeugt.

Ist UnixCompatibles ein Verb? Würde dies das $ PROFILE-Skript des Benutzers dauerhaft oder nur für diese Sitzung ändern? Ich möchte nicht, dass Get-ChildItem kompatibel ist. Lassen Sie ls ls und tun Sie, was ls tut. Es klingt so, als würde dies dem Benutzer die Wahl geben, ls durch Get-ChildItem zu ersetzen. Das ist gut. Ich bin mir nicht sicher, ob ich das will, aber für diejenigen, die es tun, ist das in Ordnung.

@Liturgist Ich denke, was @ be5invis bedeutet, ist, dass die Leute, wenn sie sich die Mühe machen, zu Powershell zu wechseln (im Gegensatz zu Bash), etwas wollen, das Powershell bietet. Wenn die Leute einen Textstrom von ls (unter Linux oder MacOS) wollten, hätten sie sich nie mit Powershell beschäftigt.

@Gaelan Also sollte ich PowerShell nicht verwenden, wenn ich gcc oder git verwenden muss? Was ist falsch daran, Leute entscheiden zu lassen, ob sie Text (ls) oder Objekte (gci) wollen? Es gibt mehr Gründe, PowerShell zu verwenden als nur seine OO-Natur - so leistungsfähig es auch ist. Heck Ich würde PowerShell lieber nur für seine C / C # -ähnlichen Kontrollflussanweisungen (vs if / fi und switch case / esac) und sein geeignetes Typsystem (wobei Zahlen Zahlen und keine Zeichenfolgen sind) verwenden.

@ Rkeithhill

Ich sollte PowerShell also nicht verwenden, wenn ich gcc oder git verwenden muss.

Wenn Benutzer auf einem * nix-System die Shell nur für gcc oder git verwenden wollten, würden sie sich nicht um PowerShell kümmern, da die mit ihrem Betriebssystem gelieferte Shell dies perfekt kann.

Heck Ich würde PowerShell lieber nur für seine C / C # -ähnlichen Kontrollflussanweisungen verwenden (vs if / fi und switch case / esac)

Wenn jemand PowerShell bereits verwendet, würde er es vielleicht deswegen bevorzugen, aber ich bezweifle, dass jemand PS nur dafür installieren würde.

das richtige Typsystem (wobei Zahlen Zahlen und keine Zeichenfolgen sind)

/bin/ls funktioniert auch nicht mit dem Typsystem: Wenn ich ls -l ausführe, erhalte ich Dateigrößen als Zeichenfolge anstelle einer richtigen PS-Nummer.

Ich denke, die Gründe, warum ein neuer Benutzer auf PS on * nix umsteigen würde, drehen sich hauptsächlich um das OO und das Typsystem. Wir sollten es neuen Benutzern so einfach wie möglich machen, mit PS zu beginnen. Wenn ich etwas über PS gesehen und versucht hätte, es auszuprobieren, nur um festzustellen, dass ich alles über die Befehlszeile neu lernen musste, um es zu verwenden, würde ich es wahrscheinlich tun Es ist viel weniger wahrscheinlich, dass ich mich darum kümmere, es zu lernen, als wenn ich PS starten könnte, ls und das Typsystem sofort in Aktion sehen könnte. Ja, ich könnte Aliase verwenden, aber wenn ich PS nur in wenigen Minuten ausprobiere, möchte ich wahrscheinlich nicht viel konfigurieren, bevor ich einspringe und anfange herumzuspielen.

Wenn Benutzer auf einem * nix-System die Shell nur für gcc oder git verwenden wollten, würden sie sich nicht um PowerShell kümmern, da die mit ihrem Betriebssystem gelieferte Shell dies perfekt kann.

Wenn jemand PowerShell bereits verwendet, würde er es vielleicht deswegen bevorzugen, aber ich bezweifle, dass jemand PS nur dafür installieren würde.

Entschuldigung, aber ich bin absolut anderer Meinung. Als Linux-Benutzer möchte ich PowerShell anstelle der mit meinem Betriebssystem gelieferten Shell verwenden. Für alles. Weil es großartig ist, weißt du :)

Ich verpacke gerade PowerShell für NixOS , um es für alles zu verwenden.

Bitte beachten Sie, dass unsere Zielbenutzer nicht nur native Unix-Benutzer sind, die versehentlich Windows + PowerShell verwenden, sondern auch Windows-Benutzer, die versehentlich Unix + PowerShell verwenden;)

Ein einzelnes Zeichen (wie ^), das automatisch in den nativen Pfad fällt

Ich würde es auch vorziehen, Aliase unter allen Betriebssystemen kompatibel zu halten, wenn sie auf diesen Plattformen gültig sind, und ein Escape-Zeichen (wie ^ls ) zu verwenden, um einen impliziten Zugriff auf native Befehle zu erhalten, wie von @joeyaiello vorgeschlagen
Ich bin nicht mit der gesamten PowersShell-Philosophie vertraut, aber was könnte an einem solchen Ansatz falsch sein?

Ein weiterer Punkt für die Verwendung eines einzelnen Zeichens: Bash macht es bereits. https://twitter.com/climagic/status/806536501232340992

\ls ignoriert alle Aliase.

Wird die Antwort auf Aliase durch Aktivieren von WSL (Windows Subsystem for Linux) gelöst? Dadurch werden native Befehle sed, awk, ls usw. in einer Bash-Shell bereitgestellt.

Obwohl es sich noch um Beta-Code für Windows 10 handelt, wird er sicherlich in Server 2016 und 2012 verfügbar sein.

@Liturgist Derzeit ist die WSL eine sehr separate Umgebung von PowerShell. Die Befehle können nicht aus einer PowerShell-Sitzung aufgerufen werden. Darüber hinaus wird dies wahrscheinlich von vielen aktuellen Windows PowerShell-Benutzern als Regression angesehen, da viele Skripts beschädigt würden, wenn sie die Ausgabe beispielsweise von GNU ls anstatt von ls -> Get-ChildItem . Während die Verwendung von Aliasen in Skripten nie empfohlen wurde, bleibt die Tatsache bestehen, dass sie verwendet wurden und ein Bruch für viele Menschen Schwierigkeiten bereiten würde.

@ Liturgist : @bgshacklett ist genau hier. Das Problem ist nicht, dass etwas passiert, wenn Sie ls . Die Frage ist, welche Parameter Sie dabei erwarten und ob die ausgegebene Ausgabe von anderen PowerShell-Cmdlets (dh ls | Where-Object Name -like *foo* objektorientiert verwendet werden kann oder nicht) ls ).

Das ursprüngliche Problem mit widersprüchlichen Aliasnamen mit nativen cmds wurde behoben. Wenn die Möglichkeit besteht, gängige Windows PowerShell-Aliase wieder hinzuzufügen, sollte dies ein separates Problem sein.

Öffnete https://github.com/PowerShell/PowerShell/issues/3610 , um das sekundäre Problem zu erfassen