Dies funktioniert ordnungsgemäß in 5.1, jedoch nicht in 6. Daher habe ich das Problem als Fehler eingestuft.

Der Grund ist, dass der aktuelle Code WriteInformation aufruft (blind?).

Siehe Zeile 751 von TestConnectionCommand.cs , auch Zeile 775 und Zeile 783.

Temporäre Problemumgehung, um zu verhindern, dass die Informationen auf dem Host angezeigt werden, ist die Verwendung des allgemeinen Parameters InformationAction . Beispiel:

Test-Connection www.microsoft.com -Count 1 -Quiet -InformationAction Continue

Aus der Sicht der Skripterstellung wäre dies kein Problem , da die Textinformationen niemals in die Pipeline geschrieben werden und die Textausgabe nicht Teil der Ergebnisdaten ist, die als an die Pipeline gesendete Daten definiert sind. Außerdem wird der Schalter Quiet definiert, um einfachere Ergebnisse zurückzugeben ( int oder bool anstelle von Aufzeichnungsobjekten). Ich muss zugeben, dass man mit Quiet nicht InformationRecord erwarten kann. Wenn ich jedoch den Grund kenne, sage ich, wir sollten InformationAction und Quiet entkoppelt halten.

In PowerShell 5.1 scheint Test-Connection WriteInformation überhaupt nicht zu nennen. Der Standardwert für $InformationPreference in PowerShell 5.1 und PowerShell Core 6.0.2 ist übrigens SilentlyContinue . Der Autor der Ausgabe hat möglicherweise einen anderen effektiven Wert, wenn er die Ausgabe reproduziert. (Vielleicht hat PS 6.1 Core den Standardwert für $InformationPreference geändert? Ich bin mir nicht sicher.)

Wenn für PS 6.1 Core $InformationPreference standardmäßig SilentlyContinue , wären die Textinformationen nur vorhanden, wenn der Benutzer ausdrücklich danach fragt.

Ich brauche mehr Feedback.
Das Problem ist, dass es im Skriptmodus und im interaktiven Modus auf unterschiedliche Weise funktionieren sollte. Im interaktiven Modus wird der Benutzer wahrscheinlich den Fortschritt (Balken) bevorzugen, wie er mit dem Befehl ping.exe geschieht. Dies gilt auch für andere Parameter.

@ mklement0 Wenn Sie Zeit haben, wäre Ihre Hilfe hilfreich.

@GeeLaw :

Guter Fund, aber in diesem Fall wird -InformationAction Ignore benötigt, um den Fehler zu umgehen.

$InformationActionPreference standardmäßig immer noch SilentlyContinue , und das sollte sich nicht ändern.

Der Fehler ist, dass die WriteInformation() -Aufrufe, die Sie verlinken, fälschlicherweise das PSHOST -Tag verwenden, das den $InformationActionPreference und auch -InformationAction SilentlyContinue umgeht (aber wie angegeben) , -InformationAction Ignore _ist_ wirksam bei der Unterdrückung der Ausgabe).

Was WriteInformation() Anrufe bewirken, ist effektiv das, was Write-Host tut, um seine Ausgabe (beabsichtigt) _bedingt_ anzuzeigen.

@iSazonov : Ich habe das Verhalten anderer Cmdlets mit Fortschrittsbalken nicht wirklich untersucht, aber mit -Quiet würde ich _nicht_ einen Fortschrittsbalken erwarten, selbst wenn ich interaktiv aufrufe.

@ mklement0 Danke für die Antwort und die Korrektur auf PSHostTag . Es scheint mir, dass InformationPreference ( InformationAction ) Ignore nicht akzeptiert? Dies gilt in 5.1 und 6.0.2. Vielleicht wurde es in 6.1 geändert. (Ist InformationActionPreference ein neuer Alias ​​für InformationPreference ?)

Außerdem war mein erster Kommentar falsch, da er InformationAction auf Continue . Die richtige Problemumgehung besteht darin, Stream 6 (Informationsstream) zu verwerfen, indem er auf $null umgeleitet wird, d. H.

Test-Connection www.microsoft.com -Count 1 -Quiet 6> $null

Überprüfen Sie die Richtigkeit wie folgt:

Write-Host 'Hello, world' 6> $null

Es sollte nichts an den Host schreiben.

@GeeLaw :

Es scheint mir, dass InformationPreference (InformationAction) Ignorieren nicht akzeptiert?

Ja, die Präferenzvariable akzeptiert nicht Ignore , der gemeinsame Parameter jedoch.

Das heißt, Sie können den Informationsstrom (Nummer 6 ) für einen bestimmten Aufruf unterdrücken, jedoch nicht für den gesamten Bereich - von Natur aus.

Daher sind die folgenden zwei Aussagen äquivalent:

Test-Connection www.microsoft.com -Count 1 -Quiet 6> $null
Test-Connection www.microsoft.com -Count 1 -Quiet -InformationAction Ignore

Mit anderen Worten: Sowohl 6> $null als auch -InformationAction Ignore sind effektive Problemumgehungen.

Ist InformationActionPreference ein neuer Alias ​​für InformationPreference ?

Nein, der Name war immer $InformationPreference , nach dem Muster von $VerbosePreference , $WarningPreference und $DebugPreference .

Soweit ich weiß, ist es nur das Paar -ErrorAction / $ErrorActionPreference bei dem der Name der Präferenzvariablen den Teil Action behält.

Abgesehen von dem Verbot von Ignore als Wert der Aktion _Präferenzvariablen_:

• Es gibt ein grundlegendes Designproblem bei dieser Einschränkung, da automatisch definierte lokale Präferenzvariablen verwendet werden, um Common-Parameter-Werte in erweiterten Funktionen zu verbreiten - siehe # 1759

• Die Einschränkung wird zum _Zuweisungszeitpunkt_ nicht erzwungen, was bedeutet, dass Sie das Problem erst sehen, wenn die Einstellung (möglicherweise implizit) beim nächsten Mal angewendet wird - siehe # 4348

  • Im Allgemeinen wird in keinem anderen Bereich als dem globalen überhaupt eine Validierung durchgeführt. Vergleiche $ErrorActionPreference = 'bogus' mit & { $ErrorActionPreference = 'bogus' } - siehe
    

    3483.

@ mklement0 Ich habe nach dem Alias ​​gefragt, weil du ihn als InformationActionPreference erwähnt hast.

Nach meinem besten Wissen setzt -XxxAction (und -Verbose und -Debug ) einfach die entsprechende Präferenzvariable im aufgerufenen Cmdlet. Wie in den about_ dokumentiert, haben wir insbesondere Folgendes:

The value of the -InformationAction parameter, if used, overrides the current value of the $InformationPreference variable.

Within the command or script in which it is used, the InformationAction common parameter overrides the value of the $InformationPreference preference variable, which by default is set to SilentlyContinue.

Ich interpretiere dies als Festlegen einer lokalen Präferenzvariablen, was durch die folgende Demonstration bestätigt werden kann:

function test-func { [cmdletbinding()]param() process { $InformationPreference } }
test-func # gives SilentlyContinue
test-func -InformationAction Continue # gives Continue
test-func -InformationAction Ignore # gives Ignore

In 5.1 und 6.0.2 akzeptiert InformationAction nicht Ignore , wie das folgende Snippet zeigt:

function test-func { [cmdletbinding()]param() process { write-information 'writing' } }
test-func -InformationAction Ignore

produziert

Write-Information : The value Ignore is not supported for an ActionPreference variable. The provided value should be used only as a value for a preference
parameter, and has been replaced by the default value. For more information, see the Help topic, "about_Preference_Variables."
At line:1 char:57
+ ...  { [cmdletbinding()]param() process { Write-Information 'writing' } }
+                                           ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Write-Information], NotSupportedException
    + FullyQualifiedErrorId : System.NotSupportedException,Microsoft.PowerShell.Commands.WriteInformationCommand

Ich frage mich, ob sich das in 6.1 geändert hat.

Es gibt noch eine andere interessante Sache: $VerbosePreference und $DebugPreference akzeptieren tatsächlich einen größeren Bereich, als durch den entsprechenden gemeinsamen Parameter festgelegt werden kann. Zum Beispiel ist es möglich, $VerbosePreference durch explizite Zuweisung auf Inquire , aber nicht möglich, indem Sie den Schalter -Verbose , da es sich schließlich um einen Schalter handelt und $True abbildet $False bis Continue / SilentlyContinue .

Soweit ich weiß, werden die präferenzbezogenen allgemeinen Parameter mit Ausnahme dieser beiden Schalter genau den entsprechenden Präferenzvariablen im lokalen Bereich zugeordnet.

Eine weitere Runde des Herumspielens zeigt, dass der folgende Code funktioniert:

Write-Information 'writing' -InformationAction Ignore

Für Entwickler wäre dies jedoch umständlich, da wir Write-Information mit dem Scheck $InformationAction -eq 'Ignore' schützen und vermeiden müssen, ihn überhaupt aufzurufen, z.

Function Test-Inf1
{
    [CmdletBinding()] Param ( )
    Process { Write-Information 'Hello, world!' }
}
Function Test-Inf2
{
    [CmdletBinding()] Param ( )
    Process { If ($InformationPreference -ne 'Ignore') { Write-Information 'Hello, world!' } }
}
Test-Inf1 -InformationAction Ignore # writes an error
Test-Inf2 -InformationAction Ignore # okay

Dies scheint auch für Autoren zu gelten, die Cmdlets mit C # schreiben.

@GeeLaw

Ich habe nach dem Alias ​​gefragt, weil Sie ihn als InformationActionPreference erwähnt haben.

Hoppla! Entschuldigung - hatte meinen eigenen Tippfehler nicht bemerkt.

Legt einfach die entsprechende Präferenzvariable im aufgerufenen Cmdlet fest.

Ja, und der Rest von dem, was Sie demonstrieren, ist Gegenstand der oben genannten # 1759.

Kurz gesagt: Der Konstruktionsfehler besteht darin, dass das Nichtzulassen von Ignore als Präferenzvariablenwert mit der Verwendung automatisch festgelegter lokaler Präferenzvariableninstanzen in Konflikt steht, um gemeinsame Parameterwerte zu verbreiten.

Genauer:

In 5.1 und 6.0.2 akzeptiert InformationAction Ignorieren nicht, wie das folgende Snippet zeigt:

Da es für die Lösung des Problems wichtig ist, möchte ich darauf hinweisen, dass -InformationAction _ Ignore akzeptiert und nur der Konstruktionsfehler das Problem verursacht, wenn die Präferenz im Kontext angewendet wird von _advanced functions_, in Ihrem Fall der Write-Information -Aufruf _inside_ the function.
Dieses Problem besteht ab PowerShell Core v6.1.0-Vorschau.2 weiterhin.

Im Gegensatz dazu haben kompilierte Cmdlets dieses Problem nicht, weshalb Write-Host foo -InformationAction Ignore wie beabsichtigt funktioniert, wie Sie seitdem festgestellt haben.

Zusammenfassend haben wir hier zwei nicht miteinander verbundene Probleme erörtert:

• Der Konstruktionsfehler in Bezug auf Ignore als Variablenwert für die Aktionspräferenz, der bereits in # 1759 verfolgt wird.

• Diese ursprüngliche Thema der Ausgabe, die misbehaving Test-Connection Cmdlets, die den fälschlicherweise verwendet PSHOST - Tag in seinen Anrufen zu .WriteInformation .

Die Lösung für letzteres besteht darin, das Tag einfach zu entfernen, wie das folgende Beispiel zeigt:

# With $InformationAction at its default, 'SilentlyContinue', this invocation is silent.
# If you set it to 'Continue', 'foo' prints.
& { [CmdletBinding()]param() $PSCmdlet.WriteInformation('foo', [string[]] @()) } 

Ich bin darauf gestoßen, weil ich das gleiche Problem habe, bei dem -Quiet nicht respektiert wird. Ich habe mir den Code angesehen und es ist ein wenig schwierig zu befolgen und sehr zu kompliziert für das, was er tut, aber ich habe nirgendwo etwas gesehen, das tatsächlich danach sucht, um die Ausgabe zu unterdrücken, und ich sehe auch nicht, woher es wechselt Ausgabe einer Zeichenfolge an einen Booleschen Wert. Dies sollte ausgegeben werden, wenn der Parameter -Quiet übergeben wird.

Ich habe letztes Jahr eine PR eingereicht (# 2537), um Test-Connection zum Code hinzuzufügen, und diese wurde zu diesem Zeitpunkt abgelehnt, weil "@ PowerShell / Powershell-Committee diese PR nicht akzeptieren würde, da dies in Zukunft zu Kompatibilitätsproblemen führen würde". Daher war ich überrascht, dass dieses Cmdlet jetzt enthalten ist, jedoch nicht mit dem Code der ursprünglichen PR, sondern mit brandneuem Code, der nicht alle erwarteten Funktionen bietet.

Das größte Problem, auf das ich stoße, ist, dass ich in meinen Skripten folgende Überprüfungen durchführe: "if (Test-Connection 8.8.8.8 -Quiet)", um in meine Logik zu verzweigen. Da der Parameter -Quiet jedoch nicht berücksichtigt wird, gibt die Verzweigung immer True zurück weil es kein Falsch oder Null gibt. Dies macht den Befehl für mich immer noch völlig unbrauchbar. Da er in neuen Versionen von PowerShell enthalten ist, ist das Upgrade für mich sehr schwierig. Bitte beheben Sie dieses Problem, da es anscheinend einige Monate her ist, seit das Problem erstmals gemeldet wurde. Entweder das oder das Wiederherstellen der ursprünglichen PR spielt keine Rolle, solange die Funktionalität zurückgegeben wird.

Ich habe letztes Jahr eine PR eingereicht, um Test-Connection zum Code hinzuzufügen, und das wurde damals abgelehnt, weil sie keine älteren Cmdlets hinzufügen wollten. Daher war ich überrascht, dass dieses Cmdlet jetzt, aber nicht im Code enthalten war der ursprünglichen PR, die vollständig war und genau wie die "Legacy" -Version funktionierte.

Wenn wir Test-Connection in 5.1 und 6.x haben, würde ich erwarten, dass sie die gleiche Ausgabe haben. Ich weiß, dass die Implementierung anders ist, aber die Benutzer sollten sich nicht darum kümmern. Die aktuelle Testverbindung in 6.1 verhält sich anders und gibt uns eine andere Ausgabe als in 5.1. Außerdem ist der Parameter -Quiet praktisch unbrauchbar.

Es scheint, dass dieses Problem immer noch besteht. Ab sofort (PSVersion = 6.2.0) zeigt das Cmdlet weiterhin die "Ping" -Informationen an, auch wenn QUIET vorhanden ist (das Hinzufügen von "-InformationAction Ignore" reicht aus, bedeutet jedoch, dass Module / Skripte verwendet werden Das Cmdlet Test-Connection muss aktualisiert werden (nicht cool).

Wäre wirklich schön, wenn wir dies für 7.0 reparieren könnten. Ich bin mehr als glücklich, den Code beizutragen, aber wir brauchen eine Implementierungsspezifikation, um zu folgen, da über frühere Versuche, dies zu verbessern, nur sehr wenig Übereinstimmung bestand.

cc @ SteveL-MSFT @iSazonov

Ich komme von Zeit zu Zeit darauf zurück. Jetzt glaube ich, dass wir dies lösen könnten, indem wir interaktive und nicht interaktive Szenarien mit expliziter Trennung mit dem Schalter -Intercative . Mit dem Parameter konnten wir eine benutzerfreundliche Konsolenausgabe implementieren. Es scheint für den Benutzer nicht zu unpraktisch zu sein, diesen Parameter (als "-i") einzugeben. Ohne den Schalter würden wir eine stark typisierte Ausgabe ohne eine verbale Konsolenausgabe machen, die für Skriptszenarien gut ist.

Angesichts der Tatsache, dass kein anderes Cmdlet einen solchen Parameter verwendet, halte ich eine solche Dualität nicht für sinnvoll. Ein Cmdlet sollte seine Aufgabe erfüllen und sich konsistent verhalten. Interaktives Verhalten sollte nicht von dem anderen Verhalten getrennt werden.

Schauen Sie sich zum Beispiel Get-ChildItem an. Interaktiv ist es dank der Standardformatierungsanzeige sehr nützlich. Es sind keine Änderungen erforderlich, um es auch für Automatisierungszwecke nützlich zu machen. Der gleiche Befehl, der interaktiv funktioniert, funktioniert auch in einem Skript.

Das ist meiner Meinung nach unnötige Komplexität.

Wir könnten die interaktive Ausgabe standardmäßig ausführen und den Parameter Quiet , um die Ausgabe in Skripten zu unterdrücken.

Wieder ... Ich sehe keine Notwendigkeit, interaktiv eine andere Ausgabe zu haben als in Skripten.

Wenn sich das Cmdlet einfach wie andere Cmdlets verhält und unbrauchbare Daten ausgibt, anstatt vollständig eindeutig zu sein und alle Daten in einem schwer zu erfassenden oder zu analysierenden Textstrom auszugeben (dies ist PowerShell, nicht Bash), ist eine Verhaltensänderung absolut nicht erforderlich .

-Quiet ist ein Schalter, der vom ursprünglichen Cmdlet in Windows PowerShell verwendet wird, um eine reine True / False-Antwort zu geben, anstatt Objekte auszugeben. Diese Konvention zu brechen ist meiner Meinung nach eine schlechte Idee.

Dieses Cmdlet sollte sich in einer Weise verhalten, die mit vorhandenen Cmdlets übereinstimmt. Es gibt keinen Grund, das aktuelle Verhalten alleine zu verwenden. In der aktuellen Iteration verhält es sich eher so, als würde man erwarten, dass ein Unix-Dienstprogramm funktioniert, ganz anders als andere PowerShell-Cmdlets.

Wieder ... Ich sehe keine Notwendigkeit, interaktiv eine andere Ausgabe zu haben als in Skripten.

Können Sie die gewünschte Ausgabe in allen unterstützten Szenarien demonstrieren? Beachten Sie, dass Metainformationen, die das Cmdlet ausgibt, sehr wichtig sind.

Ausgabe aller Daten in einem schwer zu erfassenden oder zu analysierenden Textstrom

Das Cmdlet gibt eine stark typisierte Objektausgabe aus. (Das Problem ist, dass es unmöglich ist, diese Objekte zu erstellen und gleichzeitig anzuzeigen, da "Meta" -Informationen vorhanden sind.)

-Quiet ist ein Schalter, der vom ursprünglichen Cmdlet in Windows PowerShell verwendet wird, um eine reine True / False-Antwort zu geben, anstatt Objekte auszugeben. Diese Konvention zu brechen ist meiner Meinung nach eine schlechte Idee.

Dieses Windows PowerShell-Cmdlet unterstützt nur Ping, für das das Verbindungskonzept nicht existiert. Dies war zunächst umstrittenes Design. Der richtige Name für sie wäre Test-Ping ot Test-ICMP .
Das aktuelle Cmdlet unterstützt IP-Verbindungen. Obwohl ich so etwas wie "Test-Connectivity" vorziehen würde.

In der aktuellen Iteration verhält es sich eher so, als würde man erwarten, dass ein Unix-Dienstprogramm funktioniert, ganz anders als andere PowerShell-Cmdlets.

Nein, das Cmdlet gibt eine stark typisierte Objektausgabe aus. Und die Konsolenausgabe sah aus wie Dienstprogramme. Gleichzeitig können Sie jedoch feststellen, dass es tatsächlich umfangreicher und nützlicher ist.
Das Problem ist, dass diese Ausgabe nicht mit den Funktionen des Formatierungssubsystems abgerufen werden kann und eine direkte Ausgabe an die Konsole erforderlich ist. (Beachten Sie, dass dies nicht mit Ausgabeobjekten im Ausgabestream verwechselt wird.)

Die Ausgabe kann mit dem Formatierungssystem erhalten werden, wenn wir die Datenobjekte robuster strukturieren. Ich habe bereits eine PR mit einem Prototyp eingereicht. Ein Cmdlet, das Daten in einer Form anzeigt, die die zugrunde liegenden Objektdaten nicht richtig widerspiegelt (z. B. indem Daten aus Untereigenschaften angezeigt werden, anstatt die Objektklasse richtig zu strukturieren), ist im Allgemeinen irreführend und sollte meines Erachtens nach Möglichkeit vermieden werden.

Ich werde dies weiter untersuchen und ein vollständigeres Beispiel für das zusammenstellen, was ich als gewünschte Ausgabe empfinde. Testverbindung in Windows PowerShell war vielleicht ein kontroverses Design, aber ich denke, es war ein Schritt in die richtige Richtung, wenn auch ein sehr unvollständiger.

@iSazonov Ich war nach dem ersten Lesen nicht mit Ihnen einverstanden, ABER nach dem Testen verstehe ich Ihren Standpunkt

$a=Test-Connection www.microsoft.com 
$b=Test-Connection www.microsoft.com -Quiet

Die Werte $ a und $ b sind das, was ich erwarte, ABER ich möchte keine zusätzliche Ausgabe.

Select-String hat auch einen Quiet-Parameter und nichts mit "interaktivem" Verhalten zu tun

Ich bin damit einverstanden, dass dieser Befehl einen zusätzlichen Parameter benötigt, um das Verhalten zu ändern (leise oder nicht).

Ich bevorzuge den Parameter 'Interaktiv' nicht standardmäßig, aber vielleicht ist ein Schalterparameter "NoInteractive" eine bessere Anpassung, um der interaktiven Nutzung Priorität einzuräumen.

Okay, hier ist, was ich als etwas nützlichere Implementierung betrachten würde.

Allgemeine Punkte

1. Alle aktuellen Host- / Informationsausgaben werden in den Stream -Verbose verwiesen. Derzeit wird das überhaupt nicht verwendet, und dies ist ein perfekter Anwendungsfall dafür.
2. Kein Fortschrittsbalken, sofern nicht mit einem Schalter -ShowProgress .
3. Entfernen Sie den Schalter -Ping (dies ist das Standardverhalten).

Primäre Ausgabe

Test-Connection www.google.com

• Informationen aus der Replies -Eigenschaft des Ausgabeobjekts sollten im Hauptausgabeobjekt enthalten sein, und der primäre Ausgabemodus sollte mehrere Objekte sein, die jeweils ein einzelnes Ping-Versuchs- / Antwortobjekt darstellen.
• Puffer _data_ ist im Allgemeinen irrelevant, da er nicht angegeben werden kann und nur eine BufferSize -Eigenschaft verfügbar gemacht werden sollte. Replies.Buffer Eigentum sollte private bleiben.
• Replies.Options Eigenschaft
• Die Ergebnisse werden als Tabelle ausgegeben, gruppiert nach Zieladresse (falls mehrere Ziele angegeben sind).

Visuelles Modell ausgeben

Befehl verwendet:

$Result = Test-Connection www.google.com
$Data = foreach ($Reply in $Result.Replies) {
    [PSCustomObject]@{
        Source = $Result.Source
        Destination = $Result.Destination
        Address = $Reply.Address
        RoundtripTime = $Reply.RoundtripTime
        BufferSize = $Reply.Buffer.Length
        Options = $Reply.Options
    }
}
$Data | Format-Table -GroupBy Destination -Property Source, Address, RoundtripTime, BufferSize

Resultierende Ausgabe:

   Destination: www.google.com
Source  Address       RoundtripTime BufferSize
------  -------       ------------- ----------
WS-JOEL 172.217.2.132            36         32
WS-JOEL 172.217.2.132            21         32
WS-JOEL 172.217.2.132            25         32
WS-JOEL 172.217.2.132            25         32

Test-Connection www.google.com -TraceRoute

• Jeder Hop sollte als separates Objekt ausgegeben werden, das jeweils die PingReply -Objekte als eine Eigenschaft enthält, auf die durch versteckte Formatierung zugegriffen werden kann.
• Das Hauptobjekt TraceRouteResult sollte entweder ETS- oder Klasseneigenschaften enthalten, die Zusammenfassungsdaten aus ihren vier PingReplies berechnen.
• Hinweis: Dieser von uns verwendete Objekttyp ist derzeit fehlerhaft und alle PingReply Objekte geben TtlExpired als ihren Status an. Empfehlen Sie, den Fortschritt der Korrektur für .NET Core 3 zu untersuchen oder eine benutzerdefinierte Lösung für die TraceRoute-Sicherung zu entwerfen, um das Problem zu beheben.
• Ausgabe als Tabelle, gruppiert nach DestinationHost (Warum unterscheidet sich dieser Eigenschaftsname von dem des anderen Objekttyps, der für Standard-Pings verwendet wird?)

Visuelles Modell ausgeben

Befehl verwendet:

$Result = Test-Connection www.google.com -TraceRoute
$Data = foreach ($Reply in $a.Replies) {
    [PSCustomObject]@{
        Hop = $Reply.Hop
        Source = $a.Source
        Destination = $a.DestinationHost
        DestinationAddress = $a.DestinationAddress
        Replies = $Reply.PingReplies
        RoundtripTimes = $Reply.PingReplies.RoundtripTime
        HopAddress = $Reply.PingReplies[0].Address
        BufferSize = $Reply.PingReplies.ForEach{$_.Buffer.Length}
        Options = $Reply.PingReplies[0].Options
    }
}

$Data | Format-Table -GroupBy Destination -Property Hop, RoundtripTimes, DestinationAddress, HopAddress, BufferSize

Resultierende Ausgabe:

   Destination: www.google.com
Hop RoundtripTimes DestinationAddress HopAddress     BufferSize
--- -------------- ------------------ ----------     ----------
  1 {0, 0, 0}      172.217.2.132      192.168.22.254
  2 {0, 0, 0}      172.217.2.132      75.144.219.238
  3 {0, 0, 0}      172.217.2.132      96.120.37.17
  4 {0, 0, 0}      172.217.2.132      96.110.136.65
  5 {0, 0, 0}      172.217.2.132      69.139.180.170
  6 {0, 0, 0}      172.217.2.132      68.85.127.121
  7 {0, 0, 0}      172.217.2.132      68.86.165.161
  8 {0, 0, 0}      172.217.2.132      68.86.90.205
  9 {0, 0, 0}      172.217.2.132      68.86.82.154
 10 {0, 0, 0}      172.217.2.132      66.208.233.242
 11 {0, 0, 0}      172.217.2.132      0.0.0.0
 12 {0, 0, 0}      172.217.2.132      216.239.59.124
 13 {0, 0, 0}      172.217.2.132      216.239.59.61
 14 {32, 28, 20}   172.217.2.132      172.217.2.132

Ich bin der festen Überzeugung, dass Daten, die dem Benutzer präsentiert werden, programmgesteuert leicht zugänglich sein sollten und eine ähnliche Oberflächenstruktur aufweisen wie die auf dem Bildschirm angezeigten. Das Umbenennen von Eigenschaften oder das Vergraben von Daten auf einer oder zwei Ebenen tief in einer Eigenschaft des Ausgabeobjekts führt nur zu Verwirrung, Fehlerberichten, Frustration und einer signifikanten Verringerung der allgemeinen Benutzerfreundlichkeit.

Oh, @ vexx32 Ich sehe, Sie haben nie ein Netzwerk diagnostiziert. Ihr Vorschlag wurde von mir im ersten Schritt umgesetzt und dann als nicht für die Verwendung in einer interaktiven Sitzung geeignet abgelehnt. Zum Beispiel können wir nach dem Ausführen eines Befehls Test-Connection www.google.com -TraceRoute sehr lange auf einen leeren Bildschirm schauen. Daher wurde die Implementierung geändert, um für jede Antwort eine Ausgabe (Zeichenfolge oder Fortschrittsbalken) anzuzeigen.

Alle aktuellen Host- / Informationsausgaben werden in den -Verbose-Stream verwiesen. Derzeit wird das überhaupt nicht verwendet, und dies ist ein perfekter Anwendungsfall dafür.

Mein Vorschlag oben war, den Schalter Interactive einzuführen, um interaktive und skriptbasierte Szenen aufzuteilen. Sie schlagen vor, dasselbe mit dem Schalter Verbose tun, was noch unnatürlicher ist.

Kein Fortschrittsbalken, sofern nicht mit einem -ShowProgress-Schalter angegeben.

Die Zeichenfolgenausgabe und der Fortschrittsbalken werden derzeit als zwei Alternativen implementiert. Wir brauchen nur einen. Der Fortschrittsbalken wird im Windows PowerShell-Cmdlet verwendet. Ich bevorzuge die Ausgabe von Zeichenfolgen in interaktiven Sitzungen. Es ist viel bequemer.
Und wir unterdrücken niemals einen Fortschrittsbalken mit einem Schalter. Wir haben $ ProgressPreference für Skriptszenarien. Einige Cmdlets zeigen einen Fortschrittsbalken nur für lange Operationen nach Timer an.

Entfernen Sie den -Ping-Schalter (dies ist das Standardverhalten).

Es wird empfohlen, explizite Parameter in Skripten zu verwenden. Es macht Code lesbarer. Im Windows PowerShell-Cmdlet, in dem nur Ping implementiert war, war dies nicht erforderlich. Neues Cmdlet implementiert mehr Funktionen und wir benötigen für jeden neue explizite Parameter.

Ihr Vorschlag wurde von mir im ersten Schritt umgesetzt und dann als nicht für die Verwendung in einer interaktiven Sitzung geeignet abgelehnt. Zum Beispiel können wir nach dem Ausführen eines Befehls Test-Connection www.google.com -TraceRoute sehr lange auf einen leeren Bildschirm schauen. Daher wurde die Implementierung geändert, um für jede Antwort eine Ausgabe (Zeichenfolge oder Fortschrittsbalken) anzuzeigen.

Die Fortschrittsanzeige ist beim geteilten Objektformat nicht erforderlich, da wir den Fortschritt ziemlich leicht sehen können, wenn jedes Objekt zur Ausgabe gesendet wird. Der einzige Grund, warum dies hier benötigt wird, ist, dass wir keine Daten an die Pipeline ausgeben, da diese wie jedes andere PowerShell-Cmdlet abgerufen werden. Wenn wir bei jedem PingReply oder Trace-Hop für -TraceRoute ausgeben, ist die Fortschrittsanzeige in die Ausgabeanzeige integriert.

Mein Vorschlag oben war, den interaktiven Schalter einzuführen, um interaktive und skriptbasierte Szenen aufzuteilen. Sie schlagen vor, dasselbe mit dem Verbose-Schalter zu tun, was noch unnatürlicher ist.

-Verbose ist ein allgemeiner Parameter und daher eine weitaus natürlichere Wahl für ein Cmdlet als ein völlig neuer Switch. Wir müssen das Rad hier nicht neu erfinden.

Es wird empfohlen, explizite Parameter in Skripten zu verwenden. Es macht Code lesbarer. Im Windows PowerShell-Cmdlet, in dem nur Ping implementiert war, war dies nicht erforderlich. Neues Cmdlet implementiert mehr Funktionen und wir benötigen für jeden neue explizite Parameter.

Ich bin weder hier noch da, aber normalerweise hat das Standardverhalten eines Cmdlets keinen Schalter. Zum Beispiel haben wir keinen -Loud -Schalter als Umkehrung von -Quiet .

Die Fortschrittsanzeige ist beim geteilten Objektformat nicht erforderlich, da wir den Fortschritt ziemlich leicht sehen können, wenn jedes Objekt zur Ausgabe gesendet wird.

Mit Ihrem obigen Vorschlag sammeln wir "Ping" -Objekte im "Meta" -Objekt und es ist unmöglich, die "Ping" -Objekte in Echtzeit auszugeben. Wir können nur das "Meta" -Objekt in der Pipeline ausgeben. Der Benutzer sieht zu jeder Zeit eine leere Anzeige.

-Verbose ist ein allgemeiner Parameter und daher eine weitaus natürlichere Wahl für ein Cmdlet als ein völlig neuer Schalter.

Mir ist kein Cmdlet bekannt, das wichtige Informationen an den ausführlichen Stream ausgegeben hat. Wir verwenden diesen Stream immer, um zusätzliche Diagnoseinformationen anzuzeigen, damit wir den Vorgang des Ausführens eines Cmdlets verstehen.

Normalerweise hat das Standardverhalten eines Cmdlets keinen Schalter.

Es ist richtig für einen einzelnen Parametersatz. Jetzt haben wir viele Parametersätze und müssen jeden explizit festlegen.

Mit Ihrem obigen Vorschlag sammeln wir "Ping" -Objekte im "Meta" -Objekt und es ist unmöglich, die "Ping" -Objekte in Echtzeit auszugeben. Wir können nur das "Meta" -Objekt in der Pipeline ausgeben. Der Benutzer sieht zu jeder Zeit eine leere Anzeige.

Das Metaobjekt ist nicht erforderlich. Wie im obigen Vorschlag erwähnt, werden Objekte für _each_ PingReply oder Trace Hop erstellt und ausgegeben. Das Modell ist nicht der endgültige Code, sondern lediglich ein leicht zu duplizierendes Format, um die Idee zu veranschaulichen. Jeder Eintrag in der Tabelle wird einzeln ausgegeben. Bitte lesen Sie den vollständigen Vorschlag.

Mir ist kein Cmdlet bekannt, das wichtige Informationen an den ausführlichen Stream ausgegeben hat. Wir verwenden diesen Stream immer, um zusätzliche Diagnoseinformationen anzuzeigen, damit wir den Vorgang des Ausführens eines Cmdlets verstehen.

Mir ist auch kein Cmdlet bekannt, das routinemäßig "signifikante" Informationen an die Informationen / den Host ausgibt und nur dann ausgibt, wenn es mehrere Ebenen tief in einem anderen Objekt vergraben ist.

Es ist richtig für einen einzelnen Parametersatz. Jetzt haben wir viele Parametersätze und müssen jeden explizit festlegen.

Ich denke nicht, dass dies sehr nützlich ist, aber es verursacht vermutlich keinen nennenswerten Schaden. Ich halte es einfach für Zeitverschwendung. Ich bin mir nicht sicher, ob viele Leute viel Sinn darin sehen werden, einen Schalter für das Standardverhalten anzugeben.

Das Metaobjekt ist nicht erforderlich.

Es ist kritisch notwendig.
Dieser Ansatz macht das Cmdlet nutzlos. Wenn Sie ein Netzwerk haben, in dem Probleme auftreten, versuchen Sie, mit diesem Cmdlet eine Diagnose auszuführen. Du kannst das nicht machen. Sie werden es werfen und Ping- und Traceroute-Dienstprogramme nehmen. Jetzt können Sie mit dem neuen Cmdlet sowohl in der Konsole als auch beispielsweise im Überwachungssystem mit einem Skript dieselbe Diagnose durchführen. Ich verstehe, dass es schwer zu verstehen ist, wenn Sie keine regelmäßige Netzwerkdiagnose durchführen. Sehen Sie, wie viele Parameter diese nativen Dienstprogramme haben, insbesondere in Unix-Versionen. Alle von ihnen sind wichtig für die Diagnose. Die Kunst der Diagnose besteht darin, ihre Kombinationen und magischen Bedeutungen zu verwenden. Ich habe versucht, all dies dem neuen Cmdlet hinzuzufügen.

Ich halte es einfach für Zeitverschwendung

Die Verwendung von Positionsparametern hilft Ihnen :-)

Die kurze Zusammenfassung für das PowerShell-Komitee.

Das aktuelle Cmdlet wurde entworfen

• um ein tragbares Cmdlet für alle unterstützten Plattformen zu erhalten. Wir haben wirklich noch einige Probleme in .Net Core, sodass nicht alle Funktionen auf Unix-Planformen funktionieren
• um Funktionen beliebter Tools wie Ping, Traceroute, Pathping, Portqry.exe usw. zu erhalten
• um nützliche Ausgabeobjekte in __scripts__ zu erhalten, die sowohl für eine einfache als auch für eine eingehende Analyse der Netzwerkzugänglichkeit geeignet sind
• um nützliche Konsolenausgaben mit _header_ und _footer_ zu erhalten. Beachten Sie, dass das Cmdlet in einigen Szenarien noch nützlichere Informationen anzeigt als das native Prototop-Dienstprogramm.
• um zukünftige Verbesserungen wie Remote-Tests zu ermöglichen "Test-Connection-Source ... -Destination ..."

Das Hauptproblem besteht darin, wie die interaktive Konsolenausgabe (interaktives Szenario) und die Ausgabe von Objekten in der Pipeline (Skriptszenario) kombiniert werden. Mein aktueller Vorschlag ist, eine Aufteilung entweder mit einem Parameter (-Interactive) oder mit einem neuen Cmdlet (Show-Connectivity für interaktives Szenario und Test-Connectivity für Skriptszenario) vorzunehmen.
Außerdem würde ich vorschlagen, den Namen des Cmdlets in Test -__ Connectivity__ zu ändern, was genauer ist. Es ermöglicht auch die kostenlose Verwendung des alten Windows-Cmdlets durch Proxy (WCM) ohne Namenskonflikt.

@iSazonov Können Sie ein Beispiel für eine solche Diagnose Metaobjekt erforderlich ist, das alle Daten verbirgt? Mein Vorschlag ist, die Informationen aus dem Metaobjekt in jedes PingReply-Objekt zu verschieben. Ich sehe nicht, wie dies den Nutzen des Cmdlets verringern würde.

Wie setzen Sie Statistiken von der Fußzeile zum ersten "Ping" -Objekt, wenn Sie das Objekt unmittelbar nach der Erstellung ausgeben?

Welche Fußzeileninformationen? Die einzige Fußzeileninformation von einem Ping ist Ping complete.

In den aktuellen Metaobjekten gibt es keine Statistiken, die ich irgendwo sehen kann. Sie enthalten lediglich alle Objekte mit denselben Informationen, die als Zeichenfolgendaten im Informationsstrom gerendert werden, nur in einem weniger verwendbaren Format.

Hier geht es darum, die Cmdlets (in diesem Fall Test-Connection) in beiden Versionen (WinPS und Pwsh) auf die gleiche Weise beizubehalten, indem dem Cmdlet ein Schalter hinzugefügt wird, um in diesem Fall die Ausgabe zu deaktivieren, da dies wie angegeben falsch wäre Bevor dies bedeutet, dass jedes Skript / Modul, das dieses Cmdlet verwendet, aktualisiert werden muss, wird es in beiden Versionen von der Lösung auf die gleiche Weise ausgeführt

@ NJ-Dude Windows-Cmdlet basiert auf WMI und kann nicht abwärtskompatibel portiert werden. Auch 5.1 wurde eingefroren - in Zukunft werden keine Ergänzungen mehr vorgenommen.

@ NJ-Dude Windows-Cmdlet basiert auf WMI und kann nicht abwärtskompatibel portiert werden. Auch 5.1 wurde eingefroren - in Zukunft werden keine Ergänzungen mehr vorgenommen.

Ich verstehe und weiß, dass ich nur sage, dass SYNTAX und Funktionalität gleich sein sollten. Wenn QUIET keine Ausgabe anzeigt, sollte es keine Ausgabe anzeigen, unabhängig von der verwendeten PS-Variante.

Ich sage nur, dass SYNTAX und Funktionalität gleich sein sollten

Es ist unmöglich. Das Windows-Kompatibilitätsmodul ist eine einfache Möglichkeit, die alte Funktionalität zu erhalten.

Die Ausgabe eines Cmdlets sollte gespeichert und verwendet werden können, ohne dass auch unerwünschte Anzeigen auf der Konsole, die irgendwie von der Hauptausgabe getrennt sind, manuell unterdrückt werden müssen.

Es gibt keine anderen Cmdlets, die sich so verhalten, wobei die nützlichsten Daten in Zeichenfolgenform im Informationsstrom vorliegen. Es gibt keinen Grund dafür, sich so zu verhalten. Alle Daten sollten auf dem Ausgangsstrom, period. Zusätzliche Daten befinden sich je nach Bedarf in den ausführlichen oder Debug-Streams. Die Verwendung des Informationsstroms auf diese Weise ist für ein Cmdlet, das mit PowerShell selbst geliefert wird, buchstäblich beispiellos.

Und wie bereits erwähnt, enthält die von Ihnen erwähnte Fußzeile keine Daten, die speziell in einer Fußzeile enthalten sein müssen. Es ist alles von Anfang an verfügbar oder während jede Antwort verarbeitet wird.

Anstehen für eine Ausschussdiskussion

Soooo, ich habe den Thread hier ein wenig aus den Augen verloren, weil ich Probleme im Unkraut habe, aber meine grundlegende Einstellung ohne Rücksicht auf die Implementierung lautet:

• Die Daten sollten zeilenweise ausgegeben werden. Ich denke, dass dies der aktuelle Fall bei Test-Connection s und ping.exe et al. Ist
• Daten sollten als strukturiertes Objekt zurückgegeben werden. Die Formatierung sollte dieser Tatsache nicht entsprechen. (So ​​schrecklich das auch ist, ich habe einen Formatierer gesehen, der eine JSON-Zeichenfolge an die Konsole sendet, obwohl es sich um ein PSObject unter der Haube handelt. Mein Punkt ist einfach, dass dies möglich ist.) Das Formatieren ist auch ein Ort, an dem wir arbeiten Wir dürfen ändern, was wir wollen, ohne Änderungen zu brechen. ( Stimmen Sie auch @ vexx32 nachdrücklich zu, dass wir bei Spaltenüberschriften, die nicht mit den Eigenschaftsnamen Dies ist gelegentlich für die Lesbarkeit erforderlich, macht mich aber auch verrückt.)
• -Quiet sollte genau wie Windows PowerShell nur True / False als Booleschen
• Wenn wir mehr Informationen ausgeben müssen als im Standardfall (der mehr als der minimale boolesche Fall -Quiet sein sollte), klingt -Verbose vernünftig, aber ich habe nicht genug darüber nachgedacht. (Hier verliere ich auch den Faden, schwer zu sagen, was mehr Leute oben wollen).
• Es ist unmöglich, genau dasselbe Objekt ( cimv2\Win32_PingStatus ) mit denselben Eigenschaften wie Windows PowerShell zu imitieren (weil .NET Core, WMI usw.), aber wir sollten versuchen, es so nah wie möglich zu bringen.
• Ich weiß nichts über Fortschritte. Mein hochrangiger Ansatz ist, dass der Fortschritt immer noch alle verrückt macht, weil er langsam ist (trotz unserer Optimierungen), aber auch, dass er bei nicht interaktiven Aktionen nicht so wichtig ist, weil jeder sowieso $ProgressPreference .

Klingt gut für mich!

Fortschritt nervt mich hauptsächlich, weil er im Befehlsaufruf nicht behandelt werden kann. Sie müssen $ ProgressPreference festlegen. Ich wünschte wirklich, das wäre ein gemeinsamer Parameter ... Aber ich habe noch ein anderes Problem, also lassen Sie uns hier nicht darauf eingehen! :Lächeln:

@ PowerShell / Powershell-Komitee hat dies überprüft. Wir waren uns einig, dass Test-Connection das Verhalten wie in Windows PowerShell 5.1 so genau wie möglich emulieren sollte (einschließlich -Quiet ). Dies bedeutet, dass für jede Antwort ein PingStatus -Ausgabeobjekt (Löschen des win32_ ) ausgegeben werden sollte, das die Eigenschaften im Standardformat und alle zusätzlichen verfügbaren hat. Fortschritt sollte nicht verwendet werden.

Wäre jemand bereit, einen kurzen RFC zu verfassen, der die Cmdlet-Syntax zusammen mit dem vorgeschlagenen Ausgabeformat zur Überprüfung anzeigt?

@ stevel-msft Ich würde mich freuen. :) :)

Ich liebe den Klang davon.
Vielen Dank

Es ist ein bisschen interessant, dass PR 3125 all dies abdeckte, aber die Verwendung von Test-Connection wurde abgelehnt, aber jetzt schließt sich der Kreis. Was ist mit einem Rückblick auf 3125?

Wenn man es kurz betrachtet, sieht es so aus, als hätte es Test-Connection im Wesentlichen durch einen anders implementierten Befehl auf Unix-Plattformen ersetzt, um zu versuchen, den Windows-Befehl zu emulieren. Lese ich das richtig

Ich denke nicht, dass dies die beste Option ist, die uns zur Verfügung steht. Die Konsistenz zwischen beiden Plattformen bei der Implementierung des Befehls als Ganzes ist wertvoller. Es kann einige interessante Ideen geben, die wir nutzen können, da bin ich mir sicher!

Ich werde einen Link zum RFC-Entwurf einfügen, wenn ich mit dem Schreiben fertig bin. Sie können ihn gerne kommentieren, anpassen usw. Ich würde gerne weitere Standpunkte dazu hören. 🙂

BEARBEITEN: https://github.com/PowerShell/PowerShell-RFC/pull/172

Mein spezieller Anwendungsfall, um dies zu veranlassen, basierte auf dem Wunsch, PowerShell Core unter Linux zu verwenden, aber die Implementierung wurde sowohl unter Windows als auch unter Linux vollständig getestet. Es sollte den fehlenden Befehl in seiner Gesamtheit ersetzen.

Wann werden wir das sehen? In 6.2.2? Wann wird das wahrscheinlich landen?
(Es war lustig zu sehen, wie dieser Thread von April 2018 bis jetzt über _-quiet_ tobte, laut zu sein. Scheint so ein Kinderspiel zu sein)

Ich kann diesen Code ziemlich einfach schreiben. Ich denke, ich warte nur darauf, dass der RFC akzeptiert wird. Sobald das passiert, werde ich es erledigen und eine PR dafür einreichen. :Lächeln:

Oh, ich dachte, der Status wäre, dass es genehmigt wurde (nicht genau zu wissen, welche Zustände es gibt oder wie der gesamte Prozess ist). Aber danke für das Update. Immer noch schade, dass es über 12 Monate gedauert hat, um es ruhig zu machen :)

über 12 Monate, um es ruhig zu machen

Ich habe mehr Feedback erwartet

@ vexx32 Sie können mit dem Codieren beginnen und es hinter ein Experimental-Flag setzen, falls Feedback

@ SteveL-MSFT Ich habe bereits eine meist funktionierende Implementierung. Ich werde versuchen, bald eine PR mit einigen experimentellen Flags einzureichen, damit wir konkreter über den Code sprechen können. 💖

Nachdem ich in den letzten Tagen über das gewünschte Verhalten nachgedacht habe, würde ich ein interaktives Verhalten mit einem Minimum an Parametern standardmäßig bevorzugen (schnelles Tippen und benutzerfreundliche Anzeige), was in einer interaktiven Sitzung praktisch wäre. Und Konvertieren in einen Skriptstil mit zusätzlichen Parametern (dies impliziert unterschiedliche Ausgabetypen).

Könnten Sie etwas näher erläutern, wie das Ihrer Meinung nach @isazonov funktionieren könnte?

@ vexx32 Fragen Sie nach Implementierung oder UX-Design?

Hauptsächlich, wie Sie denken, würde die UX dafür sein, denke ich. :) :)

In einer interaktiven Sitzung ist UX am besten
1. minimale Eingabe
Es bedeutet:
- Ping ist Standard
- Umschalten in einen anderen Modus (Traceroute usw.) mit einem Parameter
2. benutzerfreundliche Ausgabe
Es bedeutet:
- emulieren Sie die Ausgabe von ping.exe (tracert.exe und andere) auf dem Konsolenhost, wie ich es im Demo-Code versucht habe - mit gut formatierten Kopf-, Fuß- und Informationszeilen. Sie müssen nicht über Ausgabetypen nachdenken - sie werden nicht verwendet, sondern nur angezeigt.
- Fügen Sie Parameter hinzu, um in den Skriptmodus zu wechseln. Dies bedeutet, dass die Ausgabe von benutzerfreundlichem Text auf dem Konsolenhost unterdrückt und stark typisierte Objekte ausgegeben werden. Diese Ausgabe muss nicht formatiert werden. Wir haben Quiet besprochen, das True / False zurückgibt, aber wir benötigen einen oder mehrere Parameter, um andere stark typisierte Rohobjekte (wie -RawOutput) auszugeben. Es ist akzeptabel, dass UX zusätzliche Parameter in Skripten verwendet.

Danke, ich glaube ich verstehe, was du jetzt ein bisschen besser machst.

Ich sehe jedoch nicht wirklich die Notwendigkeit eines solchen Dual-Modus? Kein anderes Cmdlet in PowerShell weist diese Aufteilung zwischen interaktiven und "Skriptmodus" -Parametern auf.

Wenn Sie die genaue Ausgabe von Ping / Tracert wünschen, warum würden Sie diese Dienstprogramme dann nicht einfach direkt verwenden?

PowerShell hat nie erhebliche Anstrengungen unternommen, um einen vorhandenen Befehl vollständig nachzuahmen. Ich denke, Get-ChildItem ist wahrscheinlich das nächste, aber es ist fast das einzige, das dies tut.

Wenn wir die Ping / Tracert-Anzeige gründlich emulieren möchten, wie Sie sagen, würde ich vorschlagen, dass wir diese stattdessen als separates Cmdlet oder als separate Funktion verwenden, z. B. Show-Connection , anstatt Show-Command mit zusätzlichen Parametern zu überladen, die nicht vorhanden sind Präzedenzfall oder Bedarf in PowerShell.

Ich sehe jedoch nicht wirklich die Notwendigkeit eines solchen Dual-Modus? Kein anderes Cmdlet in PowerShell weist diese Aufteilung zwischen interaktiven und "Skriptmodus" -Parametern auf.

Wir haben Lücken im Formatierungssystem. Zum Beispiel haben wir ein Problem mit der Anforderung, ein Kopf- / Fußzeilenverzeichnis zu haben. Es gibt andere Szenarien, in denen dies zweckmäßig wäre.

Wenn Sie die genaue Ausgabe von Ping / Tracert wünschen, warum würden Sie diese Dienstprogramme dann nicht einfach direkt verwenden?

Ich mache :-). Diese nativen Dienstprogramme sind sehr leistungsfähig, da sie auf niedrigem Niveau sind, aber eingefroren sind. Wir können intelligentere Dinge tun als sie - dies ist die Essenz des Erscheinungsbilds dieses Cmdlets (und nicht nur, um einen Ping zu erstellen) -, wenn Sie sich genau ansehen, wie die Adressen und Namen im Cmdlet jetzt gebildet werden und wie sie sich bilden ausgegeben werden, werden Sie sehen, dass es viel nützlicher ist als im nativen Ping. Es sieht aus wie Tricks, ist aber wirklich sehr nützlich.

Natürlich haben wir Lücken im Formatierungssystem. Aber ich glaube nicht, dass die Antwort darin besteht, eine benutzerdefinierte Lösung jedes Mal zu implementieren. Das schafft nur mehr Probleme und macht es noch schwieriger, das Formatierungssystem zu verbessern oder neu zu schreiben, um auf allen Ebenen effektiver zu sein.

Ja, du hast großartige Arbeit damit geleistet! Das weiß ich sehr zu schätzen. Der aktuelle Ausgabemodus ist für nichts anderes als für die interaktive Verwendung nützlich. Wir könnten einfach den Ausgabeschritt entfernen und ihn Show-Connection und dann das, was Sie in einer stärker auf PowerShell ausgerichteten Lösung geschrieben haben, für Test-Connection selbst verwenden, wie ich im RFC skizziere.

@ vexx32 Ich habe gerade Ihre PR ausprobiert und sie wurde

PS C:\Users\slee> Test-Connection localhost

Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
------        -----------     -----------      -----------                              -----    --------
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0
SLEE-DESKTOP  localhost       127.0.0.1        ::1                                      32       0

Bei Ihrer Änderung sind jedoch alle Ping-Antworten Mitglieder eines einzelnen Objekts:

PS> Test-Connection localhost

Source       Destination Replies
------       ----------- -------
slee-desktop localhost   {System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply, System.Net.N…

Können wir das Windows PowerShell-Verhalten nicht wiederherstellen?

@ SteveL-MSFT Diese Objektausgabe hat sich seit der ersten Implementierung in PS Core nicht geändert. Die Erfolgsausgabe hatte immer das einzelne Objekt. 🙂

Wie in den abschließenden Kommentaren der PR erwähnt, ist dies nur eine teilweise Implementierung des RFC, um die Überprüfungen zu vereinfachen. Ich werde in Kürze eine Folge-PR einreichen. Sie müssen diesen Zweig nur neu gründen, um die jetzt doppelten Commits zu entfernen und den Rest zu senden, um der tatsächlichen Parität mit der Windows PowerShell-Implementierung näher zu kommen. Es wird sich immer noch etwas unterscheiden (wie aus dem RFC hervorgeht, den wir vor einigen Wochen überprüft haben), aber hoffentlich viel vielseitiger. 😊

@ SteveL-MSFT siehe # 10697 für das nächste Kapitel in diesem Abenteuer! 😊

: tada: Dieses Problem wurde in # 10478 behoben, das nun erfolgreich als v7.0.0-preview.5 .: tada:

Praktische Links:

• Versionshinweise

In Release 7.0.0 gibt Test-Connection -Quiet noch
Testverbindung: Testen der Verbindung zum Computer "bereinigt" fehlgeschlagen: Der Zielname kann nicht aufgelöst werden.
Anstatt von
Falsch

@chvol Könnten Sie bitte eine neue Ausgabe dafür mit so vielen Details wie möglich eröffnen?

Vielen Dank! 🙂