Powershell: Können wir | . verwenden? in der nächsten Zeile als Fortsetzungszeichen?

In einem Skript - ja, aber das würde die Möglichkeit beeinträchtigen, den Rechtsklick der alten Schule oder Alt + e, p in der Konsole zu verwenden, da Sie nach der Eingabe eine vollständige Befehlszeile haben.

Verwandte Diskussion #2819

Ich sehe schlechte UX für interaktive Sitzungen: Nach dem ersten NewLine wartet der Parser als nächstes NewLine oder überspringt Leerzeichen bis zu | oder NewLine - dies wird den Benutzer verwirren .

Für Skript ist dies eine Aufforderung, ein Fortsetzungszeichen ` (Backtick) rechtzeitig zu löschen, da wir immer Folgendes eingeben können:

$result = Get-Process |
     Where WS -gt 500mb |
     Format-Table VM, WS, CPU, ID, ProcessName

Der Parser tut dies bereits in anderen Orten.

if( 1 -eq (get-random 2)) {
    "True"
}
else {
    "False"
}

@lzybkr offensichtlich, dass der Parser in der Lage ist , dies zu verstehen, bedeutet nicht, dass die Leute mehrere Zeilen auf diese Weise schreiben müssen - viele Leute haben den Stroustrup-Stil wie oben übernommen oder sogar "auf ihrer eigenen Zeile geschweift" und andere Stilsachen, die das Einfügen unterbrechen (vor allem, da PSReadLine mit Rechtsklick durcheinander gebracht und Strg+V funktioniert hat). Das sollte keinen Unterschied machen.

@iSazonov interaktiv, wenn Sie die Eingabetaste else oben. Sie können shift + enter drücken, um es an der Konsole einzugeben (wenn Sie PSReadLine haben).

PSReadline funktioniert nicht mit der rechten Maustaste, obwohl es einen Eckfall gibt, in dem ein TAB-Zeichen zu etwas erweitert wird, das es ohne PSReadline nicht hätte - aber das hat mehr damit zu tun, dass die mehrzeilige Eingabe nicht so funktioniert erwartet, wenn Sie PSReadline nicht verwenden.

Aber mein Punkt war wirklich einfacher - die interaktive Erfahrung sollte so ähnlich wie möglich sein, idealerweise identisch mit dem Einfügen des gleichen Textes in ein Skript. Diese Funktion würde in einem häufig verwendeten Szenario von dieser Absicht abweichen - Rechtsklick.

An dieser Stelle sage ich, dass ich diesen Vorschlag auf die eine oder andere Weise beurteilen möchte, ich weise nur auf etwas hin, das möglicherweise nicht für jeden offensichtlich ist.

Das Einfügen mit der rechten Maustaste könnte eine Modernisierung gebrauchen, indem der gesamte Zwischenablagepuffer in die Konsole eingefügt wird, als ob Sie jede Zeile mit Umschalt + eingegeben hätten, und dann auf diese Weise ausführen. Auch ohne dieses Problem zu berücksichtigen, denke ich, dass das an sich schon nützlich wäre – wie oft haben Sie mit der rechten Maustaste etwas eingefügt, das nicht ganz richtig war (Parserfehler) und eine Reihe von Fehlermeldungen gesehen, möglicherweise mit ein paar Befehlen durchsetzt? das ausgeführt? Das könnte ziemlich schädlich sein, je nachdem, was Sie eingefügt haben (oops, der Befehl cd hat nicht richtig geparst, also bin ich in meinem aktuellen C:\-Verzeichnis geblieben, als der Befehl del *.* -r -fo ausgeführt wurde. ..). Es wäre besser, wenn mit Rechtsklick-Einfügen tatsächlich der gesamte Block eingefügt würde, und PowerShell handhabt dies bereits auf der Ausführungsseite.

Technisch gesehen unterscheidet sich die interaktive Erfahrung heute bereits vom Einfügen desselben Texts in ein Skript, da beim Einfügen mit der rechten Maustaste Befehle ausgeführt werden, während sie eingefügt werden, und nicht als eine Sammlung von Befehlen. Das Ergebnis ist, dass Parsing-Fehler eine teilweise Ausführung beim Einfügen mit der rechten Maustaste nicht verhindern, während sie dies in Skripten tun.

Ich denke auch, dass es für interaktive Ad-hoc-PowerShell ziemlich ungewöhnlich ist, dass Benutzer mehrzeilige Befehle eingeben, indem sie sie an der Konsole eingeben, und für Benutzer, die dies heute tun, können sie es wie immer tun getan. Für den Rest von uns normalen Leuten werden unsere Pipelines in einer einzigen Zeile sein, es sei denn, wir klicken mit der rechten Maustaste darauf, was, wie oben erwähnt, verbessert werden könnte und wahrscheinlich sollte, damit die interaktive Erfahrung wirklich so nah wie möglich ist , idealerweise identisch mit dem Einfügen desselben Textes in ein Skript.

Alles zu sagen: +1 dafür, dass PowerShell Pipelines am Anfang einer Zeile ohne Zeilenfortsetzungszeichen unterstützt, und eine Aufforderung, das Einfügen mit der rechten Maustaste zu korrigieren, damit eine bessere Konsistenz zwischen interaktiver Verwendung und Skripterstellung besteht.

Rechtsklick ist keine PowerShell-Funktion, sondern eine Conhost-Funktion. Conhost kann nicht immer davon ausgehen, dass die Simulation der Eingabe mit dem Einfügen identisch ist, ohne dass eine gewisse Abstimmung mit dem aktuellen Konsolenprozess erforderlich ist.

Jawohl. Es könnte das Einfügen mit der rechten Maustaste umständlich machen. Genauso macht es else .

Dies würde Befehle (sowohl in der Konsole als auch in Dateien) mit mehreren Pipes viel lesbarer machen und hat, wie bereits erwähnt, genau das gleiche Problem wie if/else, wenn es in der Eingabeaufforderung ausgeführt wird.

Bisher ein | als letztes Zeichen einer Zeile als Fortsetzungszeichen funktioniert. Was bringt diese Änderung, insbesondere wenn dadurch das bisherige Verhalten nicht mehr funktioniert?

Von meinem iPad gesendet

Am 8. März 2017 um 17:04 Uhr schrieb Michael T Lombardi < [email protected] [email protected] >:

Dies würde Befehle (sowohl in der Konsole als auch in Dateien) mit mehreren Pipes viel lesbarer machen und hat, wie bereits erwähnt, genau das gleiche Problem wie if/else, wenn es in der Eingabeaufforderung ausgeführt wird.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/PowerShell/PowerShell/issues/3020#issuecomment-285101638 an oder schalten Sie den Thread stumm https://github.com/notifications/unsubscribe-auth/AHgYUW- mDh_8nDUr671LdathDzLZPhS7ks5rjt9-gaJpZM4LohkD .

Würde diese Änderung notwendigerweise erfordern, dass ein | nicht immer noch ein Fortsetzungszeichen bei EOL _sowie_ am Anfang einer neuen Zeile sein könnte? Ich würde es nicht erwarten.

@RichardSiddaway es geht um Lesbarkeit - dies ist mehrmals in Diskussionen über Zeilenumbrüche im Practices & Style Repo aufgekommen. Einige Leute schreiben bereits so, indem sie nur Backticks am Zeilenende verwenden.

Ein Pipe-Zeichen als erstes in der Zeile macht es _wirklich_ offensichtlich, dass es sich um eine Fortsetzung handelt – viel mehr als nur ein Einrücken – besonders wenn die Zeilen lang sind und Sie das Pipe am Ende nicht leicht erkennen können.

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

vs.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

@jaykul in Ihrem Beispiel über der Einrückung ist aus Sicht der Sehschärfe genauso nützlich. Das Rohrsymbol scheint nur ein zusätzlicher (und IMO nicht benötigter) Indikator zu sein.
Spricht Sie das an Ihrem Beispiel so sehr an?

Get-Process | Where CPU | Where Path
|Get-Item | Where FullName -match "AppData"
|Sort FullName -Unique

In meinen Augen erscheint dies durchaus verständlich:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" |
    Sort FullName -Unique

es ist die Einrückung, die hilft (und so schreibe ich das normalerweise)

FWIW, ich habe die Verwendung des Backticks in langen Pipelines nie verstanden und versucht, es zu unterdrücken, wenn ich es in Code-Reviews sah, da es unnötig war.

Ich bevorzuge ausdrücklich die Pipe als erstes Zeichen, wie in Ihrem ersten Beispiel @JamesWTruher (allerdings mit einem einzelnen Leerzeichen zwischen der Pipe und dem ersten Zeichen des Befehls) - es gibt einen sehr klaren und expliziten visuellen Indikator für eine fortlaufende Pipeline . Die Einrückung gibt einen ähnlichen, aber weniger expliziten Rückschluss beim Scrollen über Code.

@Jaykul Dies wird die interaktive Befehlszeilenerfahrung vollständig

PS> dir
>

Bekommst du eine Ausgabe? Nein, das tun Sie nicht, weil der Parser auf das nächste Token wartet, das _möglicherweise_ eine Fortsetzung ist. Schlagen Sie nun auf die Return-Taste. Es passiert nichts, außer Sie sehen mehr Eingabeaufforderungen, weil der Parser noch auf ein Token wartet, um zu sehen, ob es sich um eine Fortsetzung handelt.

PS> dir
>
>

OK - füge | sort Length und drücke die Eingabetaste.

PS> dir
>
>
> | sort Length
>

Und immer noch passiert nichts, weil es _still_ möglicherweise ein Fortsetzungs-Token gibt, also muss es immer noch auf eine neue Zeile warten. Jetzt sagst du "Ich bin fertig damit - es funktioniert nicht, lass uns nur das Datum bekommen". Sie geben Get-Date und drücken die Eingabetaste. Yay - Sie erhalten Ausgabe. Aber es ist nicht von Get-Date . Nein - Sie haben endlich den Befehl dir | sort Length also ist dies die Ausgabe, die Sie sehen. In der Zwischenzeit wartet der Befehlsleser darauf, dass Sie den Befehl ausführen, den Sie mit Get-Date gestartet haben. Oder das Ganze könnte nur ein Fehler sein.

Dies wäre eine schreckliche interaktive Erfahrung für jeden Benutzer.

Könnten wir dafür sorgen, dass es nur in Dateien funktioniert? Ja - wahrscheinlich, aber wie @lzybkr erwähnte, war eines unserer

Während ich es wirklich mag, wie '|' schaut auf den Anfang der Zeile in Dingen wie Haskell Pattern Matching:
fib n | n == 0 = 1 | n == 1 = 1 | n >= 2 = fib (n-1) + fib (n-2)
es funktioniert nicht für PowerShell.

Mit dem Vorbehalt, dass ich ein neugeborenes Baby bin, wenn es um die Interna geht, hier einige Beobachtungen:

# This works everywhere
Get-Process |
Select-Object -First 1

# This errors at the prompt unless using soft returns, note the two blank lines;
# hitting enter after the first one causes it to error out.
# Note that with soft returns you can go just about forever before adding the next line.
Get-Process |


Select-Object -First 1

# This will run fine in either
If ($false) {
  ' False Output'
} Else {
  'True Output'
}
# This will error in the prompt (unless using soft returns) but pass in a file
If ($false) { 'False Output' }
Else { 'True Output' }

Abgesehen davon würde ich erwarten / in Ordnung sein, dass die folgenden Fehler in der Eingabeaufforderung ohne weiche Rückgaben fehlschlagen, wie dies bei einem nicht gekuschelten if/else der Fall ist:

Get-Process
| Select-Object -First 1

Die Lesbarkeit, insbesondere die Lesbarkeit auf einen Blick, ist mir nicht besonders wichtig, wenn ich an der Eingabeaufforderung interaktiv bin (weil ich es im Allgemeinen vor wenigen Augenblicken geschrieben habe), aber es ist eines meiner Hauptanliegen, wenn ich Skripte und Module schreibe/pflege oder die Arbeit anderer Leute debuggen usw.

Um @JamesWTruher anzusprechen – ich würde erwarten, dass die Leute keine Fortsetzungszeilen

Get-Process | Where CPU | Where Path
| Get-Item | Where FullName -match "AppData"
| Sort-Object FullName -Unique # I'm so proud of this highlighting "bug" by the way

@BrucePay Also, richtig. Die interaktive Erfahrung würde dies nicht _explizit_ unterstützen.

Wenn Sie wirklich glauben, dass es keine Unterschiede zwischen interaktiven und Skripten gibt, _Sie müssen gelegentlich versuchen, PowerShell ohne PSReadLine zu verwenden_.

Versuchen Sie es mit der Konsole in ISE oder VS Code

Sofern Sie nicht über PSReadline verfügen, um die Ausnahmen vom Typ "fehlender Anweisungsblock" oder "leeres Pipe-Element" zu behandeln, können Sie nach einem Pipe weder einen Zeilenumbruch einfügen noch geschweifte Klammern im Allman-Stil schreiben. Beides kann man sicherlich nicht schreiben:

Get-Process |
Where CPU

if($True)
{



md5-9d813a39f05f47b572d1068b0164b382



Or whether I will write the (necessary) generic `catch { "You threw $_" }` handler after



md5-6b461006504b741b884d4fb3f126b489



And it won't let me put a comment where it thinks there should be code, so neither of these is possible:



md5-adc435ab733361316365acfc69de09df



```posh
Get-Process |
# I only want actual apps, with windows
Where MainWindowHandle

Also ja, dies wäre _noch ein anderer Ort_, an dem Sie einen Zeilenumbruch im Skript haben können, aber nicht an der Konsole. Aber davon haben wir bereits viele (_besonders_ wenn Sie PSReadLine nicht verwenden).

Um auf den Code zu verweisen, den @Jaykul 1 und @JamesWTruher 2 hatten, verwende ich Folgendes :

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

Wie bereits erwähnt, erleichtert die Einrückung das Lesen beim schnellen Scannen des Codes - ich weiß, dass diese drei Codezeilen "zusammengebunden" sind, ohne auf das Ende blicken zu müssen, um das Rohr zu sehen. Lesbarkeit ist für mich eines der wichtigsten Dinge beim Schreiben von Code.

Ich füge manchmal das Backtick-Zeichen am Ende nach dem Pipe hinzu, aber wenn ich mich daran erinnere, _es wird nicht benötigt_, begeiße ich mich selbst dafür. Es ist eine Angewohnheit, die ich versuche zu brechen (der Backtick, nicht das Briching).

Das Kopieren und Einfügen in die Konsole mit PSReadline hat mir keine Probleme bereitet (ich erinnere mich), daher werde ich mich nicht mittendrin und zur Diskussion hinzufügen.

Die Pipe auf der nächsten Zeile statt an einem Zeilenende zu haben, ist eine sehr F#-ähnliche Idee, bei der Sie Dinge wie diese tun können:

F# let f1 str server = str |> parseUserName |> getUserByName server |> validateLogin <| DateTime.Now

Und ich bin für alles, was PS ein wenig funktionaler macht (Wortspiel beabsichtigt) ;)

Nicht nur F#, sondern auch Elm , Haskell , Elixir und sogar der Shell- Styleguide von

@michaeltlombardi Wie bei den Unix-Shells können Sie in PowerShell Zeilenumbrüche vermeiden, wenn Sie möchten

Get-Process | Where CPU | Where Path `
| Get-Item | Where FullName -match "AppData" `
| Sort-Object FullName -Unique

F# ist auf Leerzeichen (Abseitsregel) in einer Weise empfindlich, die PowerShell nicht ist. Elm, Haskell und Elixir sind natürlich keine Muscheln.

_Beschwerden über schlechte Gastgeber_...

Der Interpreter stellt der Hostanwendung Informationen bereit, indem er eine IncompleteParse Ausnahme auslöst. Es liegt an der Hostimplementierung, dies abzufangen und zu weiteren Eingaben aufzufordern. Wenn der Gastgeber dies falsch macht, beschweren Sie sich beim Gastgeberbesitzer.

Wenn Sie wirklich glauben, dass es keine Unterschiede zwischen interaktiven und Skripten gibt, müssen Sie ab und zu PowerShell ohne PSReadLine verwenden.

Ich habe PowerShell weit über ein Jahrzehnt ohne PSReadLine verwendet. Ist das genug?

Dieser Fehler an der Eingabeaufforderung, es sei denn, Sie verwenden Soft Returns, beachten Sie die beiden Leerzeilen;

Wie das gehandhabt wird, hängt von der Hostimplementierung ab. Eröffnen Sie ein Problem auf den beleidigenden Hosts, wenn Sie dies ändern möchten.

genau das gleiche Problem wie if/else, wenn es in der Eingabeaufforderung ausgeführt wird.

Jep. Es ist mehrdeutig. Es tut uns leid. Ich konnte mir keine Möglichkeit vorstellen, dass es zuverlässig funktioniert. Wenn wir uns für OTBS entschieden hätten, anstatt den geschweiften Stil von C# anzupassen, wäre dies nicht von Bedeutung gewesen. Tatsächlich hätte die Verwendung von OTBS (zB DSLs) viele Vorteile gebracht. Beachten Sie auch: Im ursprünglichen Konsolen-Host "funktionierte" dies, da der Host nach dem Empfang der ersten IncompleteParse Ausnahme nur Zeilen las, bis er eine leere Zeile traf, und dann das Ergebnis ausführte. Dies bedeutet jedoch, dass Sie immer einen zusätzlichen Zeilenumbruch treffen mussten.

@Jaykul Wollen Sie also das Gegenteil von F#s #light-Direktive? Etwas wie #heavy, wo Leerzeichen irrelevant und Semikolons obligatorisch sind?

Das Escapen von Zeilenumbrüchen in PS ist meiner Meinung nach problematischer als bei den meisten Sprachen. Der Escape-Charakter von PS ist der gottverdammte Backtick . Syntax-Highlighting hebt es größtenteils nicht wirklich hervor – die meisten Hervorhebungsschemata machen es zu einer ziemlich stumpfen Farbe.

Hinzu kommt die Tatsache, dass, wenn Sie zurückgehen und etwas bearbeiten, das mit Backticks übersät ist, die Wahrscheinlichkeit, dass Sie versehentlich ein oder zwei Backticks verpassen, die inmitten der Bearbeitungen verlegt wurden, ziemlich hoch ist.

Ich würde dieses Formular verwenden, wenn das Aufspüren von Backtick-Fehlern nicht so wäre, als würde man die Nadel im Heuhaufen finden. Nein, ich denke, es wäre einfach besser, das Pipe-am-Beginn-Format als eigenen Stil zuzulassen, ohne die Linie zu verlassen. :/

@vexx32 Ich stimme zu, dass '`' schwer zu erkennen ist, '|' ist nicht.

@Jaykul Wollen Sie also das Gegenteil von F#s #light-Direktive? Etwas wie #heavy, wo Leerzeichen irrelevant und Semikolons obligatorisch sind?

Nein @BrucePay , ich möchte nur einen weiteren

try { throw 5 }
catch [ArgumentException] {  <# ... #> }
catch { Write-Warning Whatever }

was mich _ordentlich_ in Skripten schreiben lässt, ohne mir Gedanken darüber zu machen, ob es funktioniert, wenn Sie in der Konsole tippen oder nicht.

@BrucePay richtig, und ich habe etwas Code, der diese Backticks verwendet, aber was wir hier suchen, ist die Möglichkeit, den Code ohne sie aus allen Gründen zu schreiben, die @vexx32 aufgelistet hat.

Es ist völlig fair, darauf hinzuweisen, dass mehrere vorhandene Verhaltensweisen in PowerShell, auf die sich die Benutzer verlassen, tatsächlich das Ergebnis der Hostimplementierung sind. Vielen Dank für die Klarstellung dieser Dinge! Auf der anderen Seite bedeutet dies auch, dass es Dinge in der Sprache gibt, die diese Erwartungen bereits brechen, es sei denn, die Hostimplementierung leistet zusätzliche Arbeit, um sie zu bewältigen, oder?

@michaeltlombardi Schlechte

Wir suchen hier die Möglichkeit, den Code ohne sie zu schreiben

Mein Punkt ist, dass, wenn Sie | an das Ende der Zeile setzen, eine Fortsetzung implizit ist und kein Fortsetzungszeichen benötigt wird, wie Sie es wünschen. Und das | Symbol ist leicht zu erkennen. Und verwenden Sie Einrückungen, um die Struktur des Codes deutlich sichtbar zu machen. Im Gegensatz zu F# oder Python erzwingen wir keine Einrückung, da PowerShell eine Shell ist und Sie manchmal sehr dichten Code schreiben müssen.

@Jaykul

ohne sich Gedanken darüber zu machen, ob es funktioniert, wenn Sie in der Konsole tippen oder nicht.

Die Konsolenerfahrung bleibt ein primäres Szenario für uns und die Mehrheit unserer Kunden. Wir haben jedoch eine Meta-Funktion zur Unterstützung experimenteller Funktionen in Vorbereitung. Wir könnten versuchen, das zu tun, was Sie wollen, als experimentelle Funktion zur Verfügung stellen und dann sehen, welche Art von Feedback wir über das Gesamterlebnis erhalten.

Ich verstehe vollkommen, dass die Konsolenerfahrung primär ist. Mein Punkt ist einfach, dass dies die Konsole nicht kaputt machen

Es sollte sich in der Konsole _so verhalten_ wie das zweite catch oben: Sie können es nur in einer Konsole eingeben, in der Sie eine mehrzeilige ReadLine wie PSReadLine haben und können Shift+Enter injizieren zusätzliche Zeile (oder Sie können sie einfügen) - es muss das vorhandene Verhalten überhaupt nicht geändert werden.

Schließlich ist dies eine Funktion, die darauf abzielt, die Codeformatierung zu verbessern und nicht die Eingabe zu reduzieren. Es muss in der Skripterstellung funktionieren, nicht in der interaktiven Konsole.

Aber eines der Versprechen, die wir dem Benutzer von Anfang an gemacht haben, war, dass Sie ein Skript (Beispiel usw.) in die Konsole einfügen und es funktionieren lassen können. Dazu gehörte sogar das Einfügen aus Word-Dokumenten mit Einbrüchen usw. Kopieren und Einfügen ist bei weitem die häufigste Form der Wiederverwendung (wir haben eine Studie durchgeführt, um dies zu validieren).

Rechts. Aber das Kopieren-Einfügen-Ding ist derzeit nur _vollständig_ wahr, solange Sie in PSReadLines Strg + V einfügen und nicht per Rechtsklick - und diese Änderung würde auch dort funktionieren . Das heißt, es würde ein mehrzeiliges Einfügen von ReadLine erfordern, aber es würde standardmäßig in PowerShell 5+ funktionieren

Wie ich oben erwähnt habe, gibt es einige Fälle (if/else, try/catch, Kommentare, Allman-Klammern usw.), in denen dies _bereits_ nicht der Fall ist, wenn Sie _kein_ PSReadLine haben.

Meiner Meinung nach ist ein weiterer Randfall in der Liste der Probleme mit Nicht-PSReadLine-Hosts kein ausreichender Grund, um ein Feature auszuschließen - schließlich würde diese Syntax in PowerShell 4 oder 5 sowieso nicht funktionieren, also Wird niemals in ISE oder den Nicht-PSReadline-Hosts funktionieren. Es _macht mich ein bisschen verrückt_, dass wir so viel Mühe darauf verwenden, ein _mehr_ Problem mit dem Einfügen in {{nicht-unser-Problem}} zu diskutieren, aber wir sind damit einverstanden, dass die Syntax in älteren Versionen nicht funktioniert PowerShell-Versionen...

PS Ich habe das Einfügen-Argument als eine der Rechtfertigungen dafür verwendet, dass die BestPractices OTBS über Stroustrup oder Allman gewählt haben , aber ich werde jetzt definitiv auf diesen Thread im Buch verweisen 😁

Ich wünschte _wirklich_ , wir wären mit OTBS gegangen. DSL wäre viel einfacher gewesen.

OTBS ist natürlich der einzig wahre Weg....

@BrucePay - Ich bin mir sicher, dass es immer noch einige Leute gibt, die mehrzeilige Befehlszeilen einfügen und nicht Strg + v verwenden , aber ich vermute, nicht so viele Leute, und sie sollten sich anpassen, ohne Rechtsklick oder Alt + Leertaste einzufügen ,e,p ist in mehrfacher Hinsicht überlegen.

Ich denke, es ist sehr vernünftig, diese Änderung in Erwägung zu ziehen.

Kann mir jemand in die richtige Richtung zeigen, was passieren müsste, damit das funktioniert? Ich würde es zumindest gerne zum Laufen bringen und sehen, wie es ist ... und dann vielleicht hinter eine experimentelle Flagge stecken, damit wir es bei Bedarf ein wenig testen können - aber ehrlich gesagt bin ich mir nicht einmal sicher, ob das ist wirklich notwendig; Schließlich ändert dies nichts an der aktuellen Erfahrung, sondern füge einfach eine neue hinzu.

Angesichts der Tatsache, dass ein Pipe-Element am Anfang einer Zeile im Ist-Zustand derzeit ein sofortiger Fehler ist, ist es kein Codierungsmuster, dem derzeit ohne die Verwendung von Escape-Neuzeilen gefolgt wird, die von dieser Änderung ebenfalls nicht betroffen sind. Also wirklich... hier nichts zu verlieren, alles zu gewinnen?

Dies wird wahrscheinlich nicht funktionieren, sollte Ihnen aber den Einstieg erleichtern:

diff --git a/src/System.Management.Automation/engine/parser/Parser.cs b/src/System.Management.Automation/engine/parser/Parser.cs
index a31f64fa0..37b897f7c 100644
--- a/src/System.Management.Automation/engine/parser/Parser.cs
+++ b/src/System.Management.Automation/engine/parser/Parser.cs
@@ -5653,6 +5653,11 @@ namespace System.Management.Automation.Language
                 }

                 pipeToken = PeekToken();
+                if (pipeToken.Kind == TokenKind.Newline)
+                {
+                    SkipNewlines();
+                    pipeToken = PeekToken();
+                }

                 switch (pipeToken.Kind)
                 {

Du hast recht, das geht nicht ganz. Zumindest teilweise, weil der Parser sich derzeit nicht um die Anzahl der Zeilenumbrüche kümmert; so viele Anweisungen werden nie ausgeführt . Ich habe einige mögliche Gedanken, wie ich vorgehen soll, also hast du mir ein faszinierendes Rätsel gegeben, danke! 💖

Threads wie dieser zeigen wirklich die immensen Vorteile, die Open Sourcing PowerShell uns gebracht hat und für uns alle eine gute und offene Diskussion mit dem Produktteam, MVPs, vertrauenswürdigen Community-Mitgliedern und solchen, die neu in dieser Sprache sind, zu ermöglichen Fantastisch. Um nur die Antwort von

Der Schlüsselteil von dem, was @Jaykul oben gesagt hat, ist, dass wir es einfacher finden, zu verstehen und zu lesen, dass die Fortsetzung eines Befehls am Anfang einer Zeile steht, im Gegensatz zum Ende einer Zeile

@RichardSiddaway es geht um Lesbarkeit - dies ist mehrmals in Diskussionen über Zeilenumbrüche im Practices & Style Repo aufgekommen. Einige Leute schreiben bereits so, indem sie nur Backticks am Zeilenende verwenden.

Ein Pipe-Zeichen als erstes in der Zeile macht es _wirklich_ offensichtlich, dass es sich um eine Fortsetzung handelt – viel mehr als nur ein Einrücken – besonders wenn die Zeilen lang sind und Sie das Pipe am Ende nicht leicht erkennen können.

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

vs.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

Also ja, das möchte ich in Zukunft gerne machen

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

Das muss ich demnächst mal wieder versuchen. Es ist ein faszinierendes Rätsel, aber ich weiß noch nicht wirklich, wie man es löst. 😕

Ich stimme beiden @kilasuit zu, dass es großartig ist, dass wir jetzt eine Open-Source-Version von PowerShell haben. Nebenbei habe ich es gestern auf Manjaro Linux installiert und war ein wenig beeindruckt, dass es alles von Grund auf neu erstellt hat. Und so schnell.

Ich stimme @RichardSiddaway auch zu, dass es gut wäre, die _Option_ zu haben, das Zeilenfortsetzungszeichen am Anfang der Zeile zu verwenden. Ich bin ein großer Verfechter der Codierung für Lesbarkeit, daher verwende ich die Einrückung (dh die erste Option) und bin damit zufrieden. Ich mag das Aussehen der zweiten Option eigentlich nicht (ich finde es sieht hässlich aus :)), aber es nimmt jede Mehrdeutigkeit daraus. Und ich bin für Leute, die die Wahl haben, wenn es die Lesbarkeit verbessert!

Letzte Nacht hatte ich Lust, am Parser herumzubasteln, und das hat mich immer genervt ( ich habe immer Pipes am Anfang der Zeile bevorzugt ). Hier ist das Ergebnis:

Die einzige Frage, die ich habe, ist, ob dies hinter einer experimentellen Flagge versteckt werden muss oder nicht. Wenn die Tests ausreichend sind, warum sollte man es dann überhaupt experimentell machen, da es keine bestehenden Funktionen beeinträchtigt? Die Gedanken?

Um es nun in einige Pester-Tests einzupacken ...

Ich glaube nicht, dass es wirklich ein experimentelles Flag braucht, vorausgesetzt, das Verhalten ist vorhersehbar, konsistent und testbar. Es bricht kein bereits bestehendes Verhalten, soweit ich das beurteilen kann.

Es scheint auch nicht wirklich so zu sein, als ob es irgendwelche Streitigkeiten über das Design gibt.

Als Randnotiz ist es auch schade, dass PowerShell zulässt, dass Befehlsnamen mit "-" beginnen. Andernfalls könnten wir wahrscheinlich auch Parameter auf Zeilenumbrüche ohne Backticks umbrechen. Sicher haben wir Splatting, aber das könnte _mit Intellisense und Syntax Highlighting_ funktionieren, wenn die Befehlsnamen nicht mit den Parameternamen übereinstimmen:

Get-AzureRmAppServicePlanMetrics
    -ResourceGroupName Default-Web-WestUS
    -Name ContosoWebApp
    -StartTime 2016-11-30T22:00:00Z
    -EndTime 2016-11-30T22:30:00Z
    -Granularity PT1M
    -Metrics Requests

Ich warte auf die Splat-ähnliche Fortsetzung, aber die Option, sie als ersten Charakter zu haben, ist definitiv großartig. Sicher ist es zwischen interaktiv und Skript unterschiedlich, aber das stimmt mit PowerShell bereits überein.

Die einzige Frage, die ich habe, ist, ob dies hinter einer experimentellen Flagge versteckt werden muss oder nicht. Wenn die Tests ausreichend sind, warum sollte man es dann überhaupt experimentell machen, da es keine bestehenden Funktionen beeinträchtigt? Die Gedanken?

Ich weiß nicht, warum das MSFT-Team beim letzten Mal so passiv ist, aber wenn Ihr Code unter einem experimentellen Tag steht, könnte ich es schnell überprüfen. Außerdem könnten wir die Funktion standardmäßig in powershell.config.json aktivieren.

Es ist schade, dass PowerShell zulässt, dass Befehlsnamen mit "-" beginnen.

Ich stimme voll und ganz zu. Ich denke, es lohnt sich, in der neuen Ausgabe ausführlich darüber zu diskutieren. (Es gibt andere Charaktere, die wir weglegen könnten.)

"Ein leeres Rohrelement ist nicht erlaubt", daher sollte es kein Bruchkompatibilitätsproblem geben, wenn gleichzeitig ein Rohr für die Linienfortsetzung und den Beginn der nächsten Linie verwendet wurde:

Get-Process | Where CPU | Where Path |
    | Get-Item | Where FullName -match "AppData" |
    | Sort FullName -Unique

Was viele der Beschwerden anspricht - keine Backticks, Pipe am Anfang einer Linie zur visuellen Anzeige der Kontinuität; keine Änderung des interaktiven Prompt-Verhaltens nach der Eingabe der ersten Zeile, da es erkennen kann, ob eine fortlaufende Zeile zu erwarten ist; hat nicht viel Verwirrung mit dem reservierten || Operator, da er auf mehrere Zeilen aufgeteilt ist; ist nicht mehr Tippen als die Verwendung eines Backticks und einer Pipe; keine Probleme mit einer Kommentarzeile dazwischen haben, wie in Jaykuls if/else , try/catch Beispielen beschrieben.

@HumanEquivalentUnit - Ich kann nicht sagen, dass ich ein Fan dieses Vorschlags bin, weil ich als Drehbuchautor entscheiden könnte, dass ich die Zeilenumbrüche innerhalb eines Skripts für die Verwendung in der Cmdline entfernen möchte und eine unpraktische und nicht intuitive einzelne Zeile übrig hätte dass IMO
sieht grauenhaft aus

Get-Process | Where CPU | Where Path |    | Get-Item | Where FullName -match "AppData" |    | Sort FullName -Unique

Welcher

@kilasuit Diese bearbeitete Zeile sieht komisch aus (sieht für mich nicht schrecklich aus, nur seltsam), aber unterscheidet sich das wirklich von Code mit Backticks, der jetzt gültig ist, wenn Sie Zeilen entfernt haben, ohne die Zeilenfortsetzung zu entfernen? Leiden Sie derzeit unter diesem Problem mit Backtick-Code?

Get-Process | Where CPU | Where Path `    | Get-Item | Where FullName -match "AppData" `    | Sort FullName -Unique

Wenn Sie mich fragen, ist das nur ein klarer Grund, warum Kirks PR willkommen ist, um ehrlich zu sein. Weder Backticks noch ein zusätzliches Rohr zu benötigen, ist beim Verdichten von Leitungen sehr praktisch.

Erste Anfrage wurde umgesetzt.
Jetzt diskutieren wir https://github.com/PowerShell/PowerShell-RFC/pull/179