Repository navigation
Need feedback for ported Test-Connection cmdlet #6557
Description
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:
- scripting functionality
- Is the design good?
- Does the cmdlet work as expected?
- interactive functionality (display output)
- 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.
- There is also a question about output headers and footers - should we emulate Windows/Linux output or should follow PowerShell output style?
Reacted by Constantine
Activity
ConstantineK commentedon Apr 7, 2018
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 commentedon Apr 7, 2018
Constantine (@ConstantineK) Thanks! Any feedback is accepted. Please add in your post that is behavior you expect.
ConstantineK commentedon Apr 7, 2018
Roger that Ilya (@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:
iSazonov commentedon Apr 8, 2018
In the example an user can be confused due to lack of output. I'd prefer to see an progress bar.
We could use our HelpersHostCS.psm1
ConstantineK commentedon Apr 8, 2018
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 commentedon Apr 8, 2018
So I was thinking something along the lines of this test passing ConstantineK@36aafe9
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 commentedon Apr 8, 2018
We must strive for compatibility with Windows PowerShell.
ConstantineK commentedon Apr 8, 2018
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 commentedon Oct 21, 2018
I got curious about the behaviour here thanks to issue #7685 being raised. The main points raised there seem to be:
Verbosestream 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.
Ilya (@iSazonov)'s point about this potential halting condition giving no output is very much valid:
I would suggest that
WriteProgressonly be used in cases where it can be reasonably expected that output will take some time -- for example, when-Countis 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 commentedon Oct 21, 2018
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 commentedon Oct 21, 2018
User might want to programmatically measure delays or lost packets.
There are still many conflicting scenarios. Otherwise, I would have done it. :-)
Is the Ctrl-C stopping not working?
vexx32 commentedon Oct 21, 2018
Well, in those instances I don't think anyone would want to use
-Quietin 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 commentedon Oct 21, 2018
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 commentedon Oct 21, 2018
-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