Powershell: Need feedback for ported Test-Connection cmdlet

[iSazonov]

Currently we merged new ported version of Test-Connection cmdlet. See description in #5328.

The cmdlet has some issues on Unixes because of .Net Core API gaps. I'll open issues in .Net Core repo.

Now we need feedbacks for Test-Connection cmdlet.
I think we should break the feedback into two parts:
1. scripting functionality
- Is the design good?
- Does the cmdlet work as expected?

1. interactive functionality (display output)
2. Now we have implemented the output to the screen as progress bar and as text (without ETS) - we have to decide what is best to use.
3. There is also a question about output headers and footers - should we emulate Windows/Linux output or should follow PowerShell output style?

[ConstantineK]

Would it also be relevant to mention that using the -Quiet parameter currently still prints output, or should that be held for a different discussion/item?

[iSazonov]

@ConstantineK Thanks! Any feedback is accepted. Please add in your post that is behavior you expect.

[ConstantineK]

Roger that @iSazonov, I was trying to write a Pester test for the behavior but I am having a bit of an issue determining how to detect the console is being written to (and then fail that test) in https://github.com/PowerShell/PowerShell/blob/master/test/powershell/Modules/Microsoft.PowerShell.Management/Test-Connection.Tests.ps1#L61.

In the case of -Quiet, the existing version's documentation states in https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-connection?view=powershell-6#optional-parameters

Indicates that this cmdlet suppresses all errors. If any pings succeed, this cmdlet returns $True. If all pings fail, this cmdlet returns $False.

What it could additionally say is that the cmdlet actually suppresses all output besides the boolean result not just errors (as far as I can tell)

When I perform the same action in PS 5.1:

PS C:\Users\ck\> Test-Connection -Destination localhost -quiet
True

[iSazonov]

Test-Connection $UnreachableAddress -Count 1000 -Quiet

In the example an user can be confused due to lack of output. I'd prefer to see an progress bar.

how to detect the console is being written

We could use our HelpersHostCS.psm1

[ConstantineK]

It might be confusing to a user, but I would argue that if they provide an additional parameter to Quiet the output, they are concretely asking for it to not present output except for true and false (as the docs say).

The use case is writing some basic application logic in PowerShell where I specifically want to suppress output, progress bars, and the rest, and just be able to simply say "is this ip address available, true or false"

I will take a look at that host helpers, thanks!

[ConstantineK]

So I was thinking something along the lines of this test passing https://github.com/ConstantineK/PowerShell/commit/36aafe937fea5c6fe339cc25da025f27d6c44321

Along the same lines I think it would be useful for the command to suppress output to the console host but still return the more complex object, so maybe my suggestion is for an entirely different switch that just suppressed the console output?

[iSazonov]

We must strive for compatibility with Windows PowerShell.

[ConstantineK]

I got you, but in that case then at least my original feedback is probably valid - in PS 5.1 -Quiet does not write to the console.

[vexx32]

I got curious about the behaviour here thanks to issue #7685 being raised. The main points raised there seem to be:

• Progress bar display is very much counter to expected display. There may be some circumstances where it is useful, but at present it is only duplicating console display unnecessarily.
• Console display is giving information that could be used programmatically, which is only being output at the end instead of outputting individual objects that could be used.
• Per the above point, all the useful information is buried in a subproperty, and the default display of the summary objects gives absolutely no information
• It was also raised that the current console display probably should be moved to the Verbose stream rather than being always output to host.

I have most of this laid out in code form as a bit of a proof-of-concept (see this comment for sample output), and I feel it is more responsive and easier to understand interactively and work with programmatically where needed... though I'm sure my code leaves something to be desired.

@iSazonov's point about this potential halting condition giving no output is very much valid:

Test-Connection $UnreachableAddress -Count 1000 -Quiet

I would suggest that WriteProgress only be used in cases where it can be reasonably expected that output will take some time -- for example, when -Count is supplied a value that is expected to take some time (e.g., any value higher than 15, or something).

Alternatively, is it at all meaningful for a user to ask for 1000 connection attempts and then ask for a true/false result? Perhaps -Count and -Quiet should be in different parameter sets? Perhaps a sensible limit should be applied to -Count when -Quiet is applied also?

[RichardSiddaway]

I think the progress bar should be an opt in feature. while

Test-Connection $UnreachableAddress -Count 1000 -Quiet

could be run its much more likely that -Count will be set to a much lower value. If I was waiting on a system becoming available I'd just test once with the test in a loop I could break out of when I got a successful result

[iSazonov]

Perhaps -Count and -Quiet should be in different parameter sets?

User might want to programmatically measure delays or lost packets.
There are still many conflicting scenarios. Otherwise, I would have done it. :-)

If I was waiting on a system

Is the Ctrl-C stopping not working?

[vexx32]

Well, in those instances I don't think anyone would want to use -Quiet in most cases... but yes, I agree that in general we shouldn't place arbitrary restrictions like that.

From my testing, Ctrl+C can seem like it isn't stopping for several seconds; the standard timeout seems to be a few seconds, and the cancellation isn't registered until the next response is received or the timeout expires. So it seems sluggish but does eventually stop.

[iSazonov]

From my testing, Ctrl+C can seem like it isn't stopping for several seconds;

We do -Count in cmdlet cycle and 4 attempts per second in CoreFX if I remember right. (CoreFX uses ping utility (!) on Unix when non-elevated)

[RichardSiddaway]

-Count and -Quiet need to be in the same parameter set as

test-Connection -Count 1 -Quiet

is a common scenario especially in scripts where you're running against a large number of machines and want to determine if you can reach a machine before proceeding with next steps