Powershell: Test-Connection on PowerShell 6.1 RC-1, Does not give correct output?

Created on 1 Sep 2018 · 37Comments · Source: PowerShell/PowerShell

Steps to reproduce

> $TestConnection = Test-Connection 8.8.8.8 -Count 3

Expected behavior

> $TestConnection = Test-Connection 8.8.8.8 -Count 3 
> $TestConnection 
Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
------        -----------     -----------      -----------                              -----    --------
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       29
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       29
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       29
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       29
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       28
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       29
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       29
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       29
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       30
MacBook-Pro... 8.8.8.8         8.8.8.8                                                   32       28

Actual behavior

> $TestConnection = Test-Connection 8.8.8.8 -Count 3 
Pinging 8.8.8.8 [8.8.8.8] with 32 bytes of data:
Reply from 8.8.8.8: bytes=0 time=31ms TTL=
Reply from 8.8.8.8: bytes=0 time=31ms TTL=
Reply from 8.8.8.8: bytes=0 time=31ms TTL= 
Ping complete.                
> $TestConnection
Source                  Destination Replies                                                                              ------                  ----------- -------                                                                              
MacBook-Pro.localdomain 8.8.8.8     {System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply...

Environment data

> $PSVersionTable
Name                           Value                                                                    ----                           -----                                                                    
PSVersion                      6.1.0-rc.1
PSEdition                      Core
GitCommitId                    6.1.0-rc.1
OS                             Darwin 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:59:21 PDT 2...
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Area-Cmdlets-Utility Issue-Discussion Resolution-Fixed

Source

ChrisRiddell

👍1

Most helpful comment

My thoughts, after playing around with the code:

Either ditch or actually, _properly_ utilise WriteProgress. Currently it displays only the exact same data as is being shown in the host output. There is no reason for its inclusion here. If, for example, it was hidden behind an _optional_ switch, or configured to display actual progress (i.e., number of pings attempted thus far out of total count being attempted) then perhaps it could be useful.
- I suspect it's simply too intrusive for what has historically been a very simple command, however.
Ditch the host output completely for everything other than -TraceRoute. It makes sense there, but given the object-oriented nature of PowerShell, there being host output by default as well as an object in the output stream is very weird and counter to the behaviour of basically every other cmdlet in existence.
- Keep this information posted to the Information stream, in my opinion, but just ditch the usage of the "PSHost" tag everywhere except in the -TraceRoute code paths so that it doesn't display by default.
As @RichardSiddaway mentions, the default display for these objects is very unusual as well. I do like the grouping by target machine. That's great. However, the default display gives basically zero information other than "there were some attempts to ping this destination".

I mean, look at it:

Source Destination Replies
------ ----------- -------
Dawn   8.8.8.8     {System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply, System.Net.Net...

Very not-useful. All you get is source and destination, which you probably already know, since you executed the command in the first place, and a bunch of meaningless type names.

I would suggest in terms of the default formatting, it ought to ditch the third column entirely (keep it structured that way internally for querying purposes), and add some new ones (both to formatting display and the actual objects):

Successes ( simple integer counting the .Replies objects with Status: Success )
Failures ( as above, but for failures )
RoundTripAverage ( as above, the average of all RoundTripTime properties from the contained .Replies objects)

So, the "summary object" _ought_ to actually be a useful summary, with the individual .Replies still present but hidden in the default formatting, while remaining readily available for the user to work with, should they need to.

Sample display of the above suggestion of default display:

Source Destination Successes Failures RoundtripAverage
------ ----------- --------- -------- ----------------
Dawn   8.8.8.8             4        0               26

Much more useful to work with, no? For reference, this is the wrangling needed to get useful display out of this command:

Test-Connection 8.8.8.8 -InformationAction Ignore |
    Select-Object -Property Source, Destination, @{
        Name       = 'Successes'
        Expression = { $_.Replies.Where{$_.Status -eq 'Success'}.Count }
    }, @{
        Name       = 'Failures'
        Expression = { $_.Replies.Where{$_.Status -eq 'Fail'}.Count }
    }, @{
        Name       = 'RoundtripAverage'
        Expression = { ($_.Replies.RoundtripTime | Measure-Object -Average).Average }
    } | Format-Table

It's a bit much, don'tcha think? 😄

Sidenote: -TraceRoute also produces differently-structured objects, and I think should have a different approach to the summary object. It probably ought to output a series of summary objects similar to the aforementioned ones, one for each host it tries to reach in the trace.

insert hacker montage for the kids

So I managed to accomplish most of this (removing write-progress, updating the standard summary object, hiding majority of host display) pretty easily and if you guys want this to change I can happily submit a PR for this.

There may be more elegant solutions available to those of you more familiar with the code, however. (Also, I need to look into how the heck output formatting is defined now...)

vexx32 on 20 Oct 2018

👍4

All 37 comments

Just want to add that the Expected behavior is what I get under Windows 10 with PS5.1 I would of expected the outputs to be uniform.

And it's annoying it outputs the Reply's as they hit to when it's should be just pushed to the var without outputting.

ChrisRiddell on 2 Sep 2018

The issue with the output extends to -quiet switch parameter as well. As well of just returning true/false, also have a visable ping reponse.

Graham-Beer on 25 Sep 2018

This is still an issue in v6.2 preview that has just been made available. is it likely to be resolved? The current output while the pings are happening is just acceptable in an interactive session but is unnecessary when running a script.

Why do we need the write-progress bar for a ping? That's just totally unnecessary when the same data is echoed in the text output.

The final output needs the replies unwrapping, Delivering a collection of .NET objects under the Replies heading doesn't make sense.

The current implementation looks like a work in progress that was abandoned.

RichardSiddaway on 18 Oct 2018

👍1

I'll take a look. It's probably relatively simple. 😄

vexx32 on 20 Oct 2018

Windows PowerShell used the WMI Win32_PingStatus class and each object in the output is an instance of Win32_PingStatus. Since WMI and that class is Windows specific, Test-Connection needed to be rewritten for ICMP pings to work cross platform. It was reimplemented using the NetInformation.Ping class. The output you see at the console which resembles the ping command output is synthetic and is written to the Information channel. If you don't want to see it, you can do:

Test-Connection foo -InformationAction Ignore

The new summary object that is returned is arguably more useful than the Win32_PingStatus instances that you would need to evaluate to determine if it was overall successful or not.

SteveL-MSFT on 20 Oct 2018

Yeah, sure you can -InformationAction Ignore, but why is that necessary to avoid polluting host output? Why does it utilise a method that is otherwise restricted to Write-Host to output data that isn't wanted, especially with the -Quiet flag applied?

It's a very un-PowerShell mode of operation, from what I can see. 😕

vexx32 on 20 Oct 2018

https://github.com/PowerShell/PowerShell/pull/5328 ported Test-Connection to using .NET APIs. There was an ask within the PR for feedback on the output, but it didn't get much attention back then. I'm open to any proposals on how we can improve the experience. cc @iSazonov

SteveL-MSFT on 20 Oct 2018

My thoughts, after playing around with the code:

Either ditch or actually, _properly_ utilise WriteProgress. Currently it displays only the exact same data as is being shown in the host output. There is no reason for its inclusion here. If, for example, it was hidden behind an _optional_ switch, or configured to display actual progress (i.e., number of pings attempted thus far out of total count being attempted) then perhaps it could be useful.
- I suspect it's simply too intrusive for what has historically been a very simple command, however.
Ditch the host output completely for everything other than -TraceRoute. It makes sense there, but given the object-oriented nature of PowerShell, there being host output by default as well as an object in the output stream is very weird and counter to the behaviour of basically every other cmdlet in existence.
- Keep this information posted to the Information stream, in my opinion, but just ditch the usage of the "PSHost" tag everywhere except in the -TraceRoute code paths so that it doesn't display by default.
As @RichardSiddaway mentions, the default display for these objects is very unusual as well. I do like the grouping by target machine. That's great. However, the default display gives basically zero information other than "there were some attempts to ping this destination".

I mean, look at it:

Source Destination Replies
------ ----------- -------
Dawn   8.8.8.8     {System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply, System.Net.Net...

Very not-useful. All you get is source and destination, which you probably already know, since you executed the command in the first place, and a bunch of meaningless type names.

Successes ( simple integer counting the .Replies objects with Status: Success )
Failures ( as above, but for failures )
RoundTripAverage ( as above, the average of all RoundTripTime properties from the contained .Replies objects)

Sample display of the above suggestion of default display:

Source Destination Successes Failures RoundtripAverage
------ ----------- --------- -------- ----------------
Dawn   8.8.8.8             4        0               26

Much more useful to work with, no? For reference, this is the wrangling needed to get useful display out of this command:

Test-Connection 8.8.8.8 -InformationAction Ignore |
    Select-Object -Property Source, Destination, @{
        Name       = 'Successes'
        Expression = { $_.Replies.Where{$_.Status -eq 'Success'}.Count }
    }, @{
        Name       = 'Failures'
        Expression = { $_.Replies.Where{$_.Status -eq 'Fail'}.Count }
    }, @{
        Name       = 'RoundtripAverage'
        Expression = { ($_.Replies.RoundtripTime | Measure-Object -Average).Average }
    } | Format-Table

It's a bit much, don'tcha think? 😄

insert hacker montage for the kids

There may be more elegant solutions available to those of you more familiar with the code, however. (Also, I need to look into how the heck output formatting is defined now...)

vexx32 on 20 Oct 2018

👍4

Using Windows PowerShell v5.1 (and earlier) I get

PS> Test-Connection 127.0.0.1

Source        Destination     IPV4Address      IPV6Address                              Bytes    Time(ms)
------        -----------     -----------      -----------                              -----    --------
W510W10       127.0.0.1       169.254.207.143  fe80::9159:497:c371:cf8f%5               32       0
W510W10       127.0.0.1       169.254.207.143  fe80::9159:497:c371:cf8f%5               32       0
W510W10       127.0.0.1       169.254.207.143  fe80::9159:497:c371:cf8f%5               32       0
W510W10       127.0.0.1       169.254.207.143  fe80::9159:497:c371:cf8f%5               32       0

One result displayed per ping

On PowerShell v6.2 preview 1 and v6.1 I get

PS>  Test-Connection 127.0.0.1
Pinging 127.0.0.1 [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
Ping complete.

Source  Destination Replies
------  ----------- -------
W510W10 127.0.0.1   {System.Net.NetworkInformation.PingReply, System.Net.NetworkInformation.PingReply, System.Net.Ne...

Plus the Write-Progress bar is visible. I agree with @vexx32 that the progress shouldn't be displayed at all. If it must be used make it an option not the default.

With regard to the text
Pinging 127.0.0.1 [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time=0ms TTL=128
etc

that is displayed again make optional - possibly through the -Verbose parameter. if I'm using Test-Connection is code I don't want this extra output.

Finally with respect to the final output - it should be a single object per ping attempt that contains

Source - already output
Destination - already output
Status from the System.Net.NetworkInformation.PingReply object
Bytes - already displayed in text so available
Time - already displayed in text so available

This makes the v6 output and usage closer to the v5.1 which will avoid a lot of user confusion and make cross platform scripting easier if there's as consistent an experience as possible.

RichardSiddaway on 20 Oct 2018

Why do we need the write-progress bar for a ping? That's just totally unnecessary when the same data is echoed in the text output.

The current implementation looks like a work in progress that was abandoned.

The current implementation is experimental port to get feedback.
There is two scenario - interactive and script - and both clash. In interactive one we want verbose console output and in script one we don't want console output.
Also we could not want progress bar for ping but want for traceroute - we need feedback for all options.

There is plans to enhance the cmdlet (pathping, detect dumb routes...).

I'll take a look. It's probably relatively simple.

There is bugs in CoreFX. We have a tracking issue. Without fixing it we can not get well working Test-Connection.
Also... @vexx32 The cmdlet is sometimes _tricky_. It does reverse lookups to show _real_ information not user input.

iSazonov on 20 Oct 2018

make cross platform scripting easier

It is absolutely impossible as @SteveL-MSFT said.

iSazonov on 20 Oct 2018

The current implementation is experimental port to get feedback.
There is two scenario - interactive and script - and both clash. In interactive one we want verbose console output and in script one we don't want console output.

There could definitely be a need for the default display in an interactive scenario. But in none of the scenarios is the WriteProgress() useful. It gives identical information to what is being passed to host. If it is kept, it should be utilised properly as suggest; otherwise, it can be removed as it really adds nothing. Additionally, -Quiet should absolutely suppress all display. That is the _dictionary definition_ of "Quiet".

There is bugs in CoreFX. We have a tracking issue. Without fixing it we can not get well working Test-Connection.

I disagree. There may be bugs, but we should make a best effort to give useful information to the user, not sit and wait while the bugs don't get fixed for months or years. The implementation can be updated when the bugs are fixed, but in the meantime it should at least be meaningfully usable in both an interactive and programmatic way.

Sidenote: Do you have a link to this issue?

Also... @vexx32 The cmdlet is sometimes tricky. It does reverse lookups to show real information not user input.

I noticed. This can simply be added to the available information in the internal PingReply objects.

After some tweaking, this is the output:

PS C:\Users\Joel\source\repos\PSCore> test-connection 8.8.8.8 | ft -property source, destination, bytes, roundtriptime, status

Source Destination Bytes RoundtripTime  Status
------ ----------- ----- -------------  ------
Dawn   8.8.8.8        32            25 Success
Dawn   8.8.8.8        32            22 Success
Dawn   8.8.8.8        32            31 Success
Dawn   8.8.8.8        32            26 Success

This took maybe a half hour, and is using the exact same information that the cmdlet already pulls from. If we add a default format for this object, the ft call is unnecessary, and it fits in perfectly well with the PS Core ecosystem.

Given that it is this easy to pull the information you would normally get into a PowerShell standard format, I see no actual need for the current status display utilising the host output. User gets the same display in a PS Core-standard format if needed, and if they want to use it programmatically it is automatically hidden instead of being a frustrating experience to suppress. As @RichardSiddaway mentions, this kind of information is typically reserved for the Verbose stream and should follow that pattern here, in my opinion.

Frankly, the fact that use of the "PSHOST" tag in WriteInformation() mandates the use of the Ignore state and does not respect SilentlyContinue on -InformationAction is itself obtuse and counter to other stream behaviours, but that's another issue.

I would love to see the cmdlet further expanded, but I think the immediate focus should be on making it somewhat comparable to the expected output from PS 5.1. It need not be identical, the objects need not be the same, but it should be relatively comparable.

There is no sense in building upon a foundation that is incomplete.

vexx32 on 20 Oct 2018

Additionally, the objects output in the case of a -Traceroute suffer the same problems; information is completely buried in the reply list properties instead of being sensibly displayed. I suspect this information may also make more sense tabulated as separate object entries with the right data, again leaving the information stream/host output unnecessary and best relegated to the Verbose stream.

Having a look. 😄

The Traceroute objects appear to be the bugged ones; the response statuses and roundtrip times don't get returned correctly. I'm guessing this is the CoreFX bug you mentioned @iSazonov?

I would agree that these should be fixed in CoreFX, but in the meantime we should code for it _as though they are fixed_ first, with some mediation for unintelligible results for better UX -- although it will show meaningless and empty data at this point in time, it will at some point be fixed (I would _hope_!) and we should be ready for it, not waiting for it to happen first.

vexx32 on 20 Oct 2018

This is where I've currently gotten, with some modifications to the cmdlet, and adding a couple properties to the summary objects it returns, as well as messing about with the default formatting (thanks be to @SeeminglyScience for helping me figure out where to put that in!) on these objects:

PS C:\Users\Joel\source\repos\PSCore> test-connection google.com

Source Destination Bytes RoundtripTime Status
------ ----------- ----- ------------- ------
Dawn   google.com      0          0 ms TimedOut
Dawn   google.com     32         54 ms Success
Dawn   google.com     32         53 ms Success
Dawn   google.com     32         55 ms Success


PS C:\Users\Joel\source\repos\PSCore> test-connection google.com -trace

Source Hop Address                        Hostname MaxRoundtrip DestinationAddress       DestinationHost
------ --- -------                        -------- ------------ ------------------       ---------------
Dawn    01 2600:1700:ee90:39c0::1                          0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    02 2001:506:6000:123:75:29:15:129                  0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    03 2001:506:6000:123:75:29:15:130                  0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    04 2001:1890:ff:ffff:12:123:12...                  0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    05 2001:1890:c01:72:12:255:10:132                  0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    06 2607:f8b0:8000:62::1:1                          0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    07 2001:4860:0:1::26f6                             0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    08 2001:4860:0:1161::3                             0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    09 2001:4860::c:4000:fd87                          0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    10 2001:4860::c:4000:dd7d                          0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    11 2001:4860::c:0:d108                             0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    12 2001:4860::2:0:9f28                             0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    13 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    14 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    15 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    16 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    17 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    18 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    19 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    20 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    21 ::                                              0 ms 2607:f8b0:400d:c00::65   google.com
Dawn    22 2607:f8b0:400d:c00::65                         54 ms 2607:f8b0:400d:c00::65   google.com

I'd appreciate any thoughts/suggestions you guys may have. I've been trying to get the formatter to snip the Address column at 24 characters, but it seems whenever it hits a nice long IPv6 address it completely ignores that, and I really don't know why.

The traceroute seems to exhibit bugged behaviour (perhaps what @iSazonov was alluding to?) in that it doesn't record proper status responses, hostnames, nor a roundtrip time for any point along the trace except the last hop.

vexx32 on 21 Oct 2018

For feedback #6557.
CoreFX issue https://github.com/dotnet/corefx/issues/28934

iSazonov on 21 Oct 2018

There is many questions. Someone can prefer progress bar. Or I'd expect that -Verbose works for -Quite. And so on.

iSazonov on 21 Oct 2018

Yep. -Verbose works with -Quiet, certainly. Thank you for the links!

I think... Really the only case I can see for the progress bar is what you mention in #6557 about the possibility for the user to specify a large number of requests to an unreachable host.

It is for that reason that I would perhaps consider having it be displayed, but if it is, it should probably display something like... Number of ping attempts to the host out of the total being attempted. Possibly traceroute would also display which hop it is on and number of pings no the current host.

However... Much of that is a non-issue if the cmdlet is outputting objects as data is being returned (even if the object only contains a _failed_ ping).

vexx32 on 21 Oct 2018

I'd prefer progress bar to be opt in

In terms of your results from the modified code

PS C:\Users\Joel\source\repos\PSCore> test-connection google.com

Source Destination Bytes RoundtripTime Status
------ ----------- ----- ------------- ------
Dawn   google.com      0          0 ms TimedOut
Dawn   google.com     32         54 ms Success
Dawn   google.com     32         53 ms Success
Dawn   google.com     32         55 ms Success

The roundriptime header should be RoundTripTime(ms) and just the numeric values are displayed. That way the value can be easily used in comparisons, sorts etc

same on MaxRoundtrip for the -Trace option

RichardSiddaway on 21 Oct 2018

👍2

I opted for this display because that header is already annoyingly wide for values that are usually quite small. The unit display is purely in formatting and the values themselves retain the same type as the original data (long).

I have a bit of a pet peeve about formatting displaying properties that don't exist and I think it's a lesser evil to display units on a numerical value than to force users to discover the real name of the property using Get-Member because the default display isn't actually giving the real property name.

vexx32 on 21 Oct 2018

Understand what you're saying but the majority of PowerShell displays put the units in the header. the Exchange cmdlets were the first I remember that didn't and that caused a huge "discussion"

RichardSiddaway on 21 Oct 2018

I have lost count of the number of times I've had the explain to people that the display is listing properties that simply don't exist and cannot be simply retrieved from the object (much more annoying with properties that are calculated at formatting time, but still a bit disingenuous with simple formatting in my opinion).

As you say, the pattern is established, so if we must follow it, so be it... But I consider it rather counterintuitive in many cases. 😆

vexx32 on 21 Oct 2018

user to specify a large number of requests to an unreachable host.

Progress bar can be useful in long time running script too. It can help an user to understand that the script is still working.

iSazonov on 21 Oct 2018

I agree. But I think that due to this reason, progress bar display should be restricted to scenarios where it can be expected that it will take some time. Otherwise it is simply intrusive. And it should absolutely be suppressed with -Quiet switch.

So, I think it should be enabled by default with -Traceroute perhaps, but not under default conditions with the standard ping behaviour.

vexx32 on 21 Oct 2018

And it should absolutely be suppressed with -Quiet switch.

Perhaps we should consider the switch as "turn on/off host output" but not progress bar that can be useful for long time operations and suppress a progress bar with -InformationAction Ignore

iSazonov on 21 Oct 2018

That would be counter to the behaviour of Write-Progress everywhere else that I've seen, unless you're aware of an example of the progress bar exhibiting that behaviour elsewhere in the code base.

I don't think we need host output, period. If we instead construct the output objects in the vein of the existing host output, then it can be either utilised for display or programmatic purposes -- or both. There is no need whatsoever for there to be separate and difficult to suppress host output from this cmdlet, in my opinion.

vexx32 on 21 Oct 2018

I don't think we need host output

It will be nice. I tried to emulate ping utility output.

iSazonov on 21 Oct 2018

Right, but why not simply emulate that in the object output, just like every other cmdlet in PowerShell? Get-ChildItem emulates or approximates display of the dir / ls command whilst actually outputting objects with the same data that is programmatically useful. Host output cannot be used in this way, cannot be piped, and is difficult to suppress (have to use -InformationAction Ignore instead of SilentlyContinue like every other stream in existence, which makes discovering the method of suppression more difficult).

This is what I have attempted to do in my brief attempt (see prior comments for initial results), and I would think that users would prefer to be able to use the displayed data over providing exact output of 1990s-era DOS/linux ping utility output.

vexx32 on 21 Oct 2018

Currently our formatting system doesn't support footers/summaries and titles-before-header-line. We have a tracking issue for dir. Here is the same problem.

iSazonov on 22 Oct 2018

My personal opinion is that we shouldn't have progress for ping as I agree it's typically a short operation that doesn't warrant progress. The information channel should be changed to verbose for those that want it. Perhaps a new switch to emit summary or per ping objects. Default should probably be the current summary object to avoid another breaking change.

SteveL-MSFT on 22 Oct 2018

There is a -Continues that emits individual ping objects until you cancel, and the -MTUSize switch does something similar, but only a single object.

If we keep the current summary object either a) the summary object's structure needs to change, and/or b) the default formatter needs to expose summary properties for the contained ping objects.

As it is, the current display of the ping summary is pretty nonexistent without the information/host display, which is probably why it was considered necessary in the first place. The immediately available properties are pretty limited without digging into the individual ping objects, as well.

vexx32 on 22 Oct 2018

@vexx32 agree that the formatting needs to be improved. I like some of the proposals you've made in this thread. However, I'm not a heavy user of Test-Connection myself so will defer to people who use it more heavily.

SteveL-MSFT on 22 Oct 2018

👍1

@vexx32 I'll look your PR although I believe we need do more design before we'll able to enhance/fix something.

iSazonov on 9 Nov 2018

❤1

I agree. I figured having some ideas set down in code to look at might help us work out possible design improvements. 😄

vexx32 on 9 Nov 2018

@vexx32 don't forget you can put it behind an Experimental Feature flag so that we can try out different options in code before deciding on a final design

SteveL-MSFT on 10 Nov 2018

!! Ah, of course!

I'll see if I can set aside the time this weekend to figure out how that will work... Might be a little tricky with how I opted to make it happen, but I'm sure I can figure something out!

vexx32 on 10 Nov 2018

I reviewed all feedbacks and I am strongly convinced that our train should go in a different direction.
I have a short message and a long one (@mklement0 sorry you had to do it :smile: ).

In short we could, can, should and must address _one main script scenario_. That is a test connection. I mean a ping with Quiet parameter. This is what is most often used in scripts. I agree that we can remove all host output. I agree that we can remove a progress bar (temporarily until the progress bar subsystem improvement).

That's all we can do today. Everything else "depends on" and I would postpone these exercises.

Long message.
I would have corrected this scenario (quiet ping) a long time ago, but every month we receive a new feedback (that is not directly related to this), which gives us hope that something more can be done.

Below are ideas I’m sure:

We should preserve standard dotnet types.
We have several issues that suggest that adding new properties to standard types degrades performance and creates other difficulties. (Although this opportunity remains very attractive.)
What is the right way? There are two ways to add new properties. Improve CoreFX. Improve formatting subsystem.

Cmdlets should not care about formatting output. This is an area for formatting subsystem.
Currently in interactive sessions a pipeline implicitly ends with Default-Output. This is what smart formatting should do. Perhaps the only smart thing that this cmdlet can do now is to collect objects with a delay and display a table, although this has side problems and looks as a hack.
_The best idea for improving the formatting subsystem is discussed in PSCore issue._
I think it is worth to make every effort to implement it as quickly as possible. I guess we can do it step by step although Jason is not sure about it.
Progress bar subsystem must be smarter.
Currently the subsystem consumes a lot of resources, does a lot of allocations, does a lot of locks, slows down scripts and it is ill suited for multi-threading.
Today there is no exact way to do it better, but we already have useful feedbacks.
Clearly this should benefit from asynchronous.

iSazonov on 10 Nov 2018

👍1

:tada:This issue was addressed in #10697, which has now been successfully released as v7.0.0-preview.6.:tada:

Handy links: