Cela fonctionne correctement dans 5.1 mais pas dans 6, j'ai donc reclassé le problème en tant que bogue.

La raison en est que le code actuel appelle WriteInformation (aveuglément?).

Voir la ligne 751 de TestConnectionCommand.cs , ainsi que la ligne 775 et la ligne 783.

Une solution temporaire pour empêcher l'affichage des informations sur l'hôte consiste à utiliser le paramètre commun InformationAction . Exemple:

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

Du point de vue des scripts , ce ne serait pas un problème , car les informations textuelles ne sont ne fait Quiet switch est défini pour renvoyer des résultats plus simples ( int ou bool , au lieu d'objets d'enregistrement). Je dois admettre que l'on ne peut pas s'attendre à InformationRecord avec Quiet . Cependant, connaissant la raison, je dis que nous ferions mieux de garder InformationAction et Quiet découplés.

Dans PowerShell 5.1, Test-Connection ne semble pas du tout appeler WriteInformation . À propos, la valeur par défaut de $InformationPreference dans PowerShell 5.1 et PowerShell Core 6.0.2 est SilentlyContinue . L'auteur du numéro peut avoir une valeur effective différente lorsqu'il reproduit le numéro. (Peut-être que PS 6.1 Core a changé la valeur par défaut de $InformationPreference ? Je ne suis pas sûr.)

Si PS 6.1 Core avait $InformationPreference défaut à SilentlyContinue , les informations textuelles ne seraient pas là à moins que l'utilisateur ne le demande explicitement.

J'ai besoin de plus de commentaires.
Le problème est qu'en mode script et en mode interactif, cela devrait fonctionner de différentes manières. En mode interactif, l'utilisateur préférera probablement voir la progression (barre) telle qu'elle se produit avec la commande ping.exe. Cela s'applique également à d'autres paramètres.

@ mklement0 Si vous avez le temps, votre aide vous sera utile.

@GeeLaw :

Bonne trouvaille, mais c'est -InformationAction Ignore qui est nécessaire dans ce cas pour contourner le bogue.

$InformationActionPreference toujours par défaut SilentlyContinue , et cela ne devrait pas changer.

Le bogue est que WriteInformation() vous appelle pour utiliser par erreur la balise PSHOST , qui _bypasse_ la $InformationActionPreference et aussi -InformationAction SilentlyContinue (mais, comme indiqué , -InformationAction Ignore _est_ efficace pour supprimer la sortie).

Ce que les appels WriteInformation() font est effectivement ce que fait Write-Host pour afficher sa sortie de manière _ inconditionnelle_ (par conception).

@iSazonov : Je n'ai pas vraiment examiné le comportement des autres applets de commande avec des barres de progression, mais avec -Quiet je ne m'attendrais pas à une barre de progression, même lors d'un appel interactif.

@ mklement0 Merci pour la réponse et la correction sur PSHostTag . Il me semble que InformationPreference ( InformationAction ) n'acceptera pas Ignore ? Cela est vrai dans les versions 5.1 et 6.0.2. Peut-être que dans la version 6.1, cela a changé. (Est-ce que InformationActionPreference un nouvel alias pour InformationPreference ?)

De plus, mon premier commentaire était erroné, car il définit InformationAction à Continue . La solution de contournement correcte consiste à supprimer le flux 6 (flux d'informations) en le redirigeant vers $null , c'est-à-dire

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

Vérifiez l'exactitude en procédant comme suit:

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

Il ne doit rien écrire à l'hôte.

@GeeLaw :

Il me semble que InformationPreference (InformationAction) n'acceptera pas Ignorer?

Oui, la _preference variable_ n'accepte pas Ignore , mais le _common parameter_ le fait.

Autrement dit, vous pouvez supprimer le flux d'informations (nombre 6 ) _ pour un appel donné_, mais pas _catégoriquement_ pour l'ensemble de la portée - par conception.

Par conséquent, les deux instructions suivantes sont équivalentes:

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

En d'autres termes: 6> $null et -InformationAction Ignore sont des solutions de contournement efficaces.

InformationActionPreference un nouvel alias pour InformationPreference ?

Non, le nom a toujours été $InformationPreference , suivant le modèle de $VerbosePreference , $WarningPreference et $DebugPreference .

D'après ce que je peux dire, il n'y a que la paire -ErrorAction / $ErrorActionPreference où le nom de la variable de préférence conserve la partie Action .

En aparté concernant l'interdiction de Ignore comme valeur de l'action _préférences variables_:

• Il y a un problème de conception fondamental avec cette restriction, car des variables de préférence locales définies automatiquement sont utilisées pour propager des valeurs de paramètres communs à l'intérieur des fonctions avancées - voir # 1759

• La restriction n'est pas appliquée à _assignment time_, ce qui signifie que vous ne verrez pas le problème jusqu'à ce que la préférence soit (éventuellement implicitement) appliquée la prochaine fois - voir # 4348

  • Plus généralement, dans n'importe quel périmètre autre que global, aucune validation n'est effectuée du tout; comparez $ErrorActionPreference = 'bogus' à & { $ErrorActionPreference = 'bogus' } - voir
    

    3483.

@ mklement0 Je demandais à propos de l'alias parce que vous l'avez mentionné comme InformationActionPreference .

À ma meilleure connaissance, -XxxAction (et -Verbose et -Debug ) définit simplement la variable de préférence correspondante dans l'applet de commande appelée. Comme indiqué dans les rubriques d'aide de about_ , nous avons en particulier les éléments suivants:

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.

J'interprète cela comme la définition d'une variable de préférence locale, comme cela peut être validé par la démonstration suivante:

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

En 5.1 et 6.0.2, InformationAction n'accepte pas Ignore , comme le montre l'extrait suivant:

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

produit

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

Je me demande si cela a changé dans la version 6.1.

Il y a une autre chose intéressante: $VerbosePreference et $DebugPreference acceptent en fait une plage plus large que celle qui peut être définie par le paramètre commun correspondant. Par exemple, il est possible de définir $VerbosePreference à Inquire par affectation explicite, mais pas possible en utilisant -Verbose switch car, après tout, c'est un switch et mappe $True / $False à Continue / SilentlyContinue .

Pour autant que je sache, à l'exception de ces deux commutateurs, les paramètres communs liés aux préférences correspondent exactement aux variables de préférence correspondantes dans la portée locale.

Un autre tour de jeu montre que le code suivant fonctionne:

Write-Information 'writing' -InformationAction Ignore

Mais cela serait fastidieux pour les développeurs, car nous devons garder Write-Information avec le chèque $InformationAction -eq 'Ignore' , et éviter de l'appeler en premier lieu, par exemple,

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

Il semble que la même chose s'applique aux auteurs qui écrivent des applets de commande avec C #.

@GeeLaw

Je vous posais des questions sur l'alias parce que vous l'avez mentionné comme InformationActionPreference.

Oops! Désolé - je n'avais pas remarqué ma propre faute de frappe.

définit simplement la variable de préférence correspondante dans l'applet de commande appelée.

Oui, et le reste de ce que vous démontrez fait l'objet du # 1759 susmentionné.

En bref: le défaut de conception est que l'interdiction de Ignore tant que valeur de variable de préférence entre en conflit avec l'utilisation d'instances de variable de préférence locale définies automatiquement afin de propager des valeurs de paramètre commun.

Plus précisement:

Dans les versions 5.1 et 6.0.2, InformationAction n'accepte pas Ignorer, comme le montre l'extrait de code suivant:

Puisqu'il est important de résoudre le problème, permettez-moi de souligner que -InformationAction _does_ accepte Ignore , et ce n'est que ledit défaut de conception qui cause le problème _ si et quand la préférence est appliquée_ dans le contexte des _fonctions avancées_, qui dans votre cas est l'appel Write-Information _à l'intérieur_ de la fonction.
Ce problème persiste à partir de PowerShell Core v6.1.0-preview.2.

Les _applets de commande compilés_, en revanche, n'ont pas ce problème, c'est pourquoi Write-Host foo -InformationAction Ignore fonctionne comme prévu, par exemple, comme vous l'avez découvert depuis.

Pour résumer, nous avons discuté ici de deux problèmes indépendants:

• Le défaut de conception par rapport à Ignore comme valeur de variable de préférence d'action, qui est déjà suivi dans # 1759.

• Le sujet original de ce problème, la cmdlet Test-Connection qui se comporte mal, qui utilise par erreur la balise PSHOST dans ses appels à .WriteInformation .

La solution à ce dernier est simplement d'omettre la balise, comme le montre l'exemple suivant:

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

Je suis donc tombé sur ça parce que je rencontre le même problème où -Quiet n'est pas respecté. J'ai regardé le code et c'est un peu difficile à suivre et très compliqué pour ce qu'il fait, mais je n'ai vu nulle part qui cherche réellement cela comme une question de suppression de la sortie, et je ne vois pas non plus d'où ça passe sortie d'une chaîne dans un booléen, ce qui devrait être produit lorsque le paramètre -Quiet est passé.

J'ai soumis un PR l'année dernière (# 2537) pour ajouter Test-Connection au code et cela a été rejeté à l'époque parce que «@ PowerShell / powershell-Committee n'accepterait pas ce PR car il introduirait des problèmes de compatibilité à l'avenir», J'ai donc été surpris de voir l'inclusion de cette applet de commande maintenant, mais pas avec le code du PR d'origine, mais plutôt un tout nouveau code qui ne fournit pas toutes les fonctionnalités attendues.

Le plus gros problème que je rencontre est dans mes scripts, j'effectue des vérifications comme celle-ci, «if (Test-Connection 8.8.8.8 -Quiet)» pour brancher dans ma logique, mais avec le paramètre -Quiet non respecté, la branche renvoie toujours True car il n'y a pas de False ou Null. Cela rend donc la commande encore totalement inutilisable pour moi, et depuis qu'elle a été incluse dans les nouvelles versions de PowerShell, cela rend la mise à niveau très délicate pour moi. Veuillez corriger cela car il semble que cela fait plusieurs mois que le problème a été signalé pour la première fois. Soit cela, soit rétablir le PR d'origine, n'a pas d'importance tant que la fonctionnalité est retournée.

J'ai soumis un PR l'année dernière pour ajouter Test-Connection au code et cela a été rejeté à l'époque car ils ne voulaient pas ajouter des applets de commande héritées, j'ai donc été surpris de voir l'inclusion de cette applet de commande maintenant mais pas avec le code du PR original qui était complet et fonctionnait exactement comme la version «héritée».

Si nous avons Test-Connection en 5.1 et 6.x, je m'attendrais à ce qu'ils aient le même résultat. Je sais que la mise en œuvre est différente, mais les utilisateurs ne devraient pas s'en soucier. Le Test-Connection actuel en 6.1 se comporte différemment en nous donnant une sortie différente de celle en 5.1. En plus de cela, le paramètre -Quiet est pratiquement inutile.

Il semble que ce problème persiste, à partir de maintenant (PSVersion = 6.2.0) la cmdlet continue d'afficher les informations "ping" même si QUIET est présent (l'ajout de "-InformationAction Ignore" fait l'affaire mais cela signifie que les modules / scripts utilisent l'applet de commande Test-Connection devra être mise à jour, pas cool)

Ce serait vraiment bien si nous pouvions résoudre ce problème pour la version 7.0. Je suis plus qu'heureux de contribuer au code, mais nous avons besoin d'une spécification d'implémentation à suivre car il y avait très peu d'accord sur les tentatives précédentes pour améliorer cela.

cc @ SteveL-MSFT @iSazonov

J'y reviens de temps en temps. Maintenant, je crois que nous pourrions résoudre cela en utilisant une séparation explicite des scénarios interactifs et non interactifs avec le commutateur -Intercative . Avec le paramètre, nous pourrions implémenter une sortie de console riche et conviviale. Il semble que ce n'est pas trop gênant pour l'utilisateur de taper ce paramètre (comme "-i"). Sans le commutateur, nous ferions une sortie typée forte sans sortie de console verbeuse, ce qui est bon pour les scénarios de script.

Étant donné qu'aucune autre applet de commande n'utilise un tel paramètre, je ne pense pas qu'il soit logique d'avoir une telle dualité. Une applet de commande doit effectuer sa tâche et se comporter de manière cohérente; Le comportement interactif ne doit pas être séparé de la façon dont il se comporte autrement.

Par exemple, regardez Get-ChildItem. De manière interactive, il est très utile grâce à l'affichage du formateur par défaut. Aucun changement n'est nécessaire pour le rendre également utile à des fins d'automatisation; la même commande qui fonctionne de manière interactive fonctionne également dans un script.

C'est une complexité inutile, je pense.

Nous pourrions faire la sortie interactive par défaut et améliorer le paramètre Quiet pour supprimer la sortie dans les scripts.

Encore une fois ... je ne vois pas la nécessité d'avoir une sortie différente de manière interactive par rapport aux scripts.

Si l'applet de commande se comporte simplement comme d'autres applets de commande et génère des données inutilisables au lieu d'être complètement unique et de sortir toutes ses données dans un flux de texte difficile à capturer ou à analyser (il s'agit de _PowerShell_, pas de Bash), il n'est absolument pas nécessaire de modifier le comportement .

-Quiet est un commutateur utilisé par l'applet de commande d'origine dans Windows PowerShell pour donner une réponse True / False pure, au lieu de générer des objets. Briser cette convention est une mauvaise idée, à mon avis.

Cette applet de commande doit se comporter de manière cohérente avec les applets de commande existantes. Il n'y a aucune raison de le laisser utiliser seul le comportement actuel. Dans son itération actuelle, il se comporte davantage comme on s'attendrait à ce qu'un utilitaire Unix fonctionne, très différent du fonctionnement des autres applets de commande PowerShell.

Encore une fois ... je ne vois pas la nécessité d'avoir une sortie différente de manière interactive par rapport aux scripts.

Pouvez-vous faire une démonstration de la sortie souhaitée dans tous les scénarios pris en charge? Notez que les méta-informations que la cmdlet génère sont très importantes.

sortie de toutes ses données dans un flux de texte difficile à capturer ou à analyser

L'applet de commande effectue une sortie d'objets typés forts. (Le problème est qu'il est impossible de construire ces objets et de les afficher simultanément car il y a des "méta" informations.)

-Quiet est un commutateur utilisé par l'applet de commande d'origine dans Windows PowerShell pour donner une réponse True / False pure, au lieu de générer des objets. Briser cette convention est une mauvaise idée, à mon avis.

Cette cmdlet Windows PowerShell prend uniquement en charge le ping pour lequel le concept de connexion n'existe pas. C'était initialement une conception controversée. Le bon nom pour eux serait Test-Ping ot Test-ICMP .
L'applet de commande actuelle prend en charge les «connexions» IP. Bien que je préfère quelque chose comme "Test-Connectivity".

Dans son itération actuelle, il se comporte davantage comme on s'attendrait à ce qu'un utilitaire Unix fonctionne, très différent du fonctionnement des autres applets de commande PowerShell.

Non, l'applet de commande effectue une sortie d'objets typés forts. Et la sortie de la console a été conçue pour ressembler à des utilitaires. Mais en même temps, vous constaterez peut-être qu'en fait, il est plus riche et plus utile.
Le problème est que cette sortie ne peut pas être obtenue en utilisant les capacités du sous-système de formatage et il est nécessaire de faire une sortie directe vers la console. (Notez que cela ne se mélange pas avec les objets de sortie dans le flux de sortie)

La sortie peut être obtenue avec le système de formatage, si nous structurons les objets de données de manière plus robuste. J'ai déjà soumis un PR avec un prototype. Une applet de commande qui affiche des données sous une forme qui ne reflète pas correctement les données d'objet sous-jacentes (par exemple, en affichant des données à partir de sous-propriétés au lieu de structurer correctement la classe d'objet) est généralement trompeuse et à mon avis à éviter dans la mesure du possible.

J'examinerai cela plus en détail et rassemblerai un exemple plus complet de ce que je perçois comme le résultat souhaité. Test-Connection dans Windows PowerShell a peut-être été une conception controversée, mais je pense que c'était un pas dans la bonne direction, bien que très incomplet.

@iSazonov Je n'étais pas d'accord avec vous après la première lecture MAIS après les tests, je comprends votre point de vue

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

Les valeurs $ a et $ b sont ce à quoi je m'attends MAIS je ne veux pas de sortie supplémentaire.

Select-String a également un paramètre silencieux et n'a rien à voir avec le comportement "interactif"

Je suis d'accord que cette commande a besoin d'un paramètre supplémentaire pour changer le comportement (silencieux ou non).

Je préfère le paramètre 'Interactive' pas par défaut mais peut-être qu'un paramètre de commutateur "NoInteractive" est un meilleur ajustement pour laisser la priorité sur l'utilisation interactive.

Très bien, voici ce que je considérerais comme une mise en œuvre un peu plus utile.

Points généraux

1. Toute la sortie actuelle de l'hôte / des informations est reléguée au flux -Verbose . Actuellement, cela n'est pas utilisé du tout, et c'est un cas d'utilisation parfait pour cela.
2. Aucune barre de progression sauf si spécifié avec un commutateur -ShowProgress .
3. Supprimez le commutateur -Ping (c'est le comportement par défaut).

Sortie principale

Test-Connection www.google.com

• Les informations de la propriété Replies de l'objet de sortie doivent être incluses dans l'objet de sortie principal, et le mode de sortie principal doit être des objets _multiple_, chacun représentant un seul objet de tentative / réponse de ping.
• Buffer _data_ n'est généralement pas pertinent, car il ne peut pas être spécifié, et seule une propriété BufferSize doit être exposée. Replies.Buffer propriété doit rester private .
• Replies.Options propriété
• Résultats de sortie sous forme de tableau, regroupés par adresse de destination (dans le cas où plusieurs destinations sont spécifiées).

Maquette visuelle de sortie

Commande utilisée:

$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

Sortie résultante:

   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

• Chaque saut doit être généré en tant qu'objet séparé, chacun contenant les objets PingReply tant que propriété accessible en masquant le formatage.
• L'objet principal TraceRouteResult doit contenir soit ETS, soit des propriétés de classe qui calculent les données récapitulatives à partir de leurs quatre PingReplies.
• Remarque: Ce type d'objet que nous utilisons est actuellement bogué , et tous les objets PingReply rapportent TtlExpired comme leur état. Nous vous recommandons d'étudier la progression du correctif pour .NET Core 3 ou de concevoir une solution personnalisée pour le support TraceRoute afin de résoudre le problème.
• Sortie sous forme de table, regroupée par DestinationHost (Pourquoi ce nom de propriété est-il différent de celui de l'autre type d'objet utilisé pour les pings standard?)

Maquette visuelle de sortie

Commande utilisée:

$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

Sortie résultante:

   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

Je suis fermement convaincu que si nous présentons des données à l'utilisateur, elles devraient être facilement accessibles de manière programmatique, avec une structure de surface similaire à ce qui est affiché à l'écran. Renommer des propriétés ou enfouir des données à un ou deux niveaux dans une propriété de l'objet de sortie ne fait qu'inviter la confusion, les rapports de bogue, la frustration et une diminution significative de la convivialité globale.

Oh, @ vexx32 Je vois que vous n'avez jamais diagnostiqué un réseau. Votre proposition a été mise en œuvre par moi dans la première étape, puis rejetée car elle ne convient pas à une utilisation dans une session interactive. Par exemple, nous pouvons regarder un écran vide pendant très longtemps après avoir exécuté une commande Test-Connection www.google.com -TraceRoute . L'implémentation a donc été modifiée pour afficher une sortie (chaîne ou barre de progression) pour chaque réponse.

Toute la sortie actuelle de l'hôte / des informations est reléguée dans le flux -Verbose. Actuellement, ce n'est pas du tout utilisé, et c'est un cas d'utilisation parfait pour cela.

Ma suggestion ci-dessus était d'introduire le commutateur Interactive pour séparer les scénarios interactifs et script. Vous suggérez de faire de même avec le commutateur Verbose , ce qui est une pratique encore plus artificielle.

Aucune barre de progression sauf si spécifié avec un commutateur -ShowProgress.

La sortie de chaîne et la barre de progression sont dans l'implémentation actuelle comme deux alternatives. Nous n'avons besoin que d'un seul. La barre de progression est utilisée dans l'applet de commande Windows PowerShell. Ma préférence est la sortie de chaîne en session interactive. C'est beaucoup plus pratique.
Et nous ne supprimons jamais une barre de progression avec un interrupteur. Nous avons $ ProgressPreference pour les scénarios de script. Certaines applets de commande affichent une barre de progression uniquement pour les opérations longues par minuterie.

Supprimez le commutateur -Ping (c'est le comportement par défaut).

La meilleure pratique consiste à utiliser des paramètres explicites dans les scripts. Cela rend le code plus lisible. Cela n'était pas nécessaire dans l'applet de commande Windows PowerShell où seul le ping était implémenté. La nouvelle applet de commande implémente plus de fonctionnalités et nous avons besoin d'un nouveau paramètre explicite pour chacune d'entre elles.

Votre proposition a été mise en œuvre par moi dans la première étape, puis rejetée car elle ne convient pas à une utilisation dans une session interactive. Par exemple, on peut regarder un écran vide pendant très longtemps après avoir exécuté une commande Test-Connection www.google.com -TraceRoute. L'implémentation a donc été modifiée pour afficher une sortie (chaîne ou barre de progression) pour chaque réponse.

L'affichage de la progression n'est pas nécessaire avec le format d'objet fractionné, car nous pouvons assez facilement voir la progression lorsque chaque objet est soumis à la sortie. La seule raison pour laquelle il est nécessaire ici est que nous ne générons pas de données vers le pipeline telles qu'elles sont récupérées comme toutes les autres applets de commande PowerShell. Si nous sortons à chaque PingReply ou saut de trace pour -TraceRoute nous _avons_ un affichage de progression intégré à l'affichage de sortie.

Ma suggestion ci-dessus était d'introduire le commutateur interactif pour séparer les scénarios interactifs et scénarisés. Vous suggérez de faire de même avec le commutateur Verbose, ce qui est encore plus une pratique non naturelle.

-Verbose est un paramètre commun et donc un choix beaucoup plus naturel pour une applet de commande qu'un tout nouveau commutateur. Nous n'avons pas besoin de réinventer la roue ici.

La meilleure pratique consiste à utiliser des paramètres explicites dans les scripts. Cela rend le code plus lisible. Cela n'était pas nécessaire dans l'applet de commande Windows PowerShell où seul le ping était implémenté. La nouvelle applet de commande implémente plus de fonctionnalités et nous avons besoin d'un nouveau paramètre explicite pour chacune d'entre elles.

Je ne suis ni ici ni là-dessus, mais le comportement par défaut d'une applet de commande n'a généralement pas de commutateur. Par exemple, nous n'avons pas -Loud commutateur -Quiet .

L'affichage de la progression n'est pas nécessaire avec le format d'objet fractionné, car nous pouvons assez facilement voir la progression lorsque chaque objet est soumis à la sortie.

Avec votre proposition ci-dessus, nous collectons des objets "ping" dans un objet "meta" et il est impossible de sortir les objets "ping" en temps réel - nous ne pouvons sortir en pipeline que l'objet "méta" - l'utilisateur verra un affichage vide en tout temps.

-Verbose est un paramètre commun et donc un choix beaucoup plus naturel pour une applet de commande qu'un tout nouveau commutateur.

Je ne connais aucune applet de commande qui produisait des informations importantes dans le flux détaillé. Nous utilisons toujours ce flux pour afficher des informations de diagnostic supplémentaires afin de comprendre le processus d'exécution d'une cmdlet.

généralement, le comportement par défaut d'une applet de commande n'a pas de commutateur.

Il convient pour un seul jeu de paramètres. Nous avons maintenant de nombreux ensembles de paramètres et nous devons les désigner explicitement chacun.

Avec votre proposition ci-dessus, nous collectons des objets "ping" dans un objet "meta" et il est impossible de sortir les objets "ping" en temps réel - nous ne pouvons sortir en pipeline que l'objet "méta" - l'utilisateur verra un affichage vide en tout temps.

Le méta-objet est inutile. Comme mentionné dans la proposition ci-dessus, les objets seraient créés et sortis pour _each_ PingReply ou trace hop. La maquette n'est pas le code final, mais simplement un format facile à dupliquer pour illustrer l'idée. Chaque entrée du tableau serait sortie une par une. Veuillez lire la proposition complète.

Je ne connais aucune applet de commande qui produisait des informations importantes dans le flux détaillé. Nous utilisons toujours ce flux pour afficher des informations de diagnostic supplémentaires afin de comprendre le processus d'exécution d'une cmdlet.

Je ne suis pas non plus au courant des applets de commande _any_ qui produisent régulièrement des informations "significatives" vers les informations / l'hôte et ne les produisent pas, sauf enfouies plusieurs niveaux profondément dans un autre objet.

Il convient pour un seul jeu de paramètres. Nous avons maintenant de nombreux ensembles de paramètres et nous devons les désigner explicitement chacun.

Je ne pense pas qu'il y ait beaucoup d'utilité à le faire, mais cela ne crée pas beaucoup de tort, je suppose. Je pense simplement que c'est une perte de temps; Je ne suis pas sûr que beaucoup de gens verront une grande utilité à spécifier un commutateur pour le comportement par défaut.

Le méta-objet est inutile.

_Il est indispensable._
Cette approche rend la cmdlet inutile. Si vous disposez d'un réseau présentant des problèmes, essayez d'exécuter un diagnostic à l'aide de cette cmdlet. Tu ne peux pas faire ça. Vous le lancerez et utiliserez les utilitaires ping et traceroute. Mais maintenant, vous pouvez effectuer les mêmes diagnostics avec la nouvelle cmdlet à la fois dans la console et, par exemple, dans le système de surveillance avec un script. Je comprends qu'il est difficile de comprendre si vous ne faites pas de diagnostics réseau réguliers. Découvrez le nombre de paramètres de ces utilitaires natifs, en particulier dans les versions Unix. Tous sont importants pour le diagnostic. L'art du diagnostic consiste à utiliser leurs combinaisons et leurs significations magiques. J'ai essayé d'ajouter tout cela à la nouvelle cmdlet.

Je pense simplement que c'est une perte de temps

L'utilisation des paramètres de position vous aide :-)

Le bref résumé de PowerShell Committee.

L'applet de commande actuelle a été conçue

• pour obtenir une applet de commande portable pour toutes les plates-formes prises en charge. Vraiment, nous avons encore quelques problèmes dans .Net Core, donc toutes les fonctionnalités ne fonctionnent pas sur les plans Unix
• pour obtenir des fonctionnalités d'outils populaires tels que ping, traceroute, pathping, Portqry.exe, etc.
• pour obtenir des objets de sortie utiles dans __scripts__ adaptés à une analyse simple et approfondie de l'accessibilité du réseau
• pour obtenir une sortie de console utile avec _header_ et _footer_. Notez que l'applet de commande affiche des informations encore plus utiles dans certains scénarios que l'utilitaire de prototope natif.
• pour permettre de futures améliorations comme les tests à distance "Test-Connection -Source ... -Destination ..."

Le problème principal est de savoir comment combiner la sortie de la console interactive (scénario interactif) et la sortie des objets dans le pipeline (scénario de script). Ma suggestion actuelle est de faire un fractionnement avec un paramètre (-Interactive) ou avec une nouvelle cmdlet (Show-Connectivity pour le scénario interactif et Test-Connectivity pour le scénario de script).
Je suggère également de changer le nom de l'applet de commande en Test -__ Connectivity__, ce qui est plus précis. Il permettra également l'utilisation gratuite de l'ancienne applet de commande Windows via le proxy (WCM) sans conflit de nom.

@iSazonov pouvez-vous fournir un exemple d'un tel diagnostic qui nécessite qu'il y ait un méta-objet qui cache toutes les données? Ma proposition est de déplacer les informations du méta-objet vers chaque objet PingReply; Je ne vois pas comment cela diminuerait l'utilité de l'applet de commande.

Comment mettre les statistiques du pied de page au premier objet "ping" si vous sortez l'objet immédiatement après sa création?

Quelles informations de pied de page? La seule information de pied de page d'un ping est Ping complete.

Il n'y a pas de statistiques dans les objets méta actuels que je peux voir n'importe où; ils contiennent simplement tous les objets avec les mêmes informations qui sont rendus sous forme de données de chaîne sur le flux d'informations, juste dans un format moins utilisable.

Le point ici est de garder les applets de commande (dans ce cas Test-Connection) de la même manière sur les deux versions (WinPS et Pwsh) en ajoutant un commutateur à l'applet de commande dans ce cas pour `` désactiver '' cette sortie serait erronée car comme je l'ai dit avant que cela signifie que chaque script / module utilisant cette applet de commande devra être mis à jour, la solution le fait de la même manière sur les deux versions

L'applet de commande Windows @ NJ-Dude est basée sur WMI et il est impossible de la porter avec une compatibilité descendante. 5.1 a également été gelé - aucun ajout ne sera à l'avenir.

L'applet de commande Windows @ NJ-Dude est basée sur WMI et il est impossible de la porter avec une compatibilité descendante. 5.1 a également été gelé - aucun ajout ne sera à l'avenir.

Je comprends et je sais que, je dis simplement que SYNTAX et les fonctionnalités devraient être les mêmes, ce qui signifie que si l'utilisation de QUIET n'affiche aucune sortie, elle ne doit afficher aucune sortie quelle que soit la saveur du PS utilisé.

Je dis juste que le SYNTAX et la fonctionnalité devraient être les mêmes

C'est impossible. Le module de compatibilité Windows est un moyen unique d'obtenir l'ancienne fonctionnalité.

La sortie d'une applet de commande doit pouvoir être stockée et utilisée sans avoir à supprimer manuellement l'affichage indésirable sur la console, qui est en quelque sorte séparé de la sortie principale.

Il n'y a _aucune autre applet de commande_ qui se comporte de cette façon, où les données les plus utiles sont sous forme de chaîne sur le flux d'informations. Il n'y a aucune raison pour qu'il se comporte de cette façon. Toutes les données doivent être sur le flux de sortie, point final . Des données supplémentaires se trouvent sur les flux détaillés ou de débogage selon les besoins. L'utilisation du flux d'informations de cette manière est littéralement sans précédent pour une applet de commande fournie avec PowerShell lui-même.

Et comme mentionné, il n'y a aucune donnée dans le pied de page que vous mentionnez qui doit être spécifiquement dans un pied de page; tout est disponible dès le début ou au fur et à mesure que chaque réponse est traitée.

Mise en file d'attente pour une discussion du comité

Soooo j'ai un peu perdu la trace du fil ici, ayant des problèmes dans les mauvaises herbes, mais ma prise de base sans égard à la mise en œuvre est la suivante:

• Les données doivent être sorties ligne par ligne. Je pense que c'est le cas actuel avec Test-Connection s et ping.exe et al
• Les données doivent être renvoyées sous la forme d'un objet structuré. Le formatage doit être indépendant de ce fait. (Aussi horrible que cela puisse être, j'ai vu un formateur qui émet une chaîne JSON sur la console malgré le fait que c'est un PSObject sous le capot. Mon point est simplement que cela peut être fait.) Le formatage est aussi un endroit où nous sont autorisés à changer ce que nous voulons sans casser les changements. (Également tout à fait d'accord avec @ vexx32 pour
• -Quiet ne devrait rien émettre sauf True / False en tant que booléen, tout comme Windows PowerShell.
• S'il y a plus d'informations que nous devons émettre que le cas par défaut (qui devrait être plus que le cas booléen minimal -Quiet ), -Verbose semble raisonnable, mais je n'y ai pas suffisamment réfléchi. (C'est aussi là que je perds le fil, difficile de dire ce que veulent plus de gens ci-dessus).
• Imiter exactement le même objet ( cimv2\Win32_PingStatus ) avec toutes les mêmes propriétés que Windows PowerShell est impossible (car .NET Core, WMI, etc.), mais nous devrions essayer de le rapprocher le plus possible.
• Je ne connais pas les progrès. Mon point de vue de haut niveau est que les progrès rendent tout le monde fou parce que c'est lent (malgré nos optimisations), mais aussi que cela n'a pas tellement d'importance dans le non-interactif car tout le monde définit de toute façon $ProgressPreference .

Ça me semble bien!

Le progrès me dérange principalement parce qu'il ne peut pas être géré dans l'appel de commande; vous devez définir $ ProgressPreference. Je souhaite vraiment que ce soit un paramètre commun ... Mais j'ai un autre problème à ce sujet, alors n'entrons pas dans cela ici! :sourire:

@ PowerShell / PowerShell-Committee a examiné cela. Nous avons convenu que Test-Connection devrait émuler le plus fidèlement possible le comportement de Windows PowerShell 5.1 (y compris -Quiet ). Cela signifie qu'un objet de sortie PingStatus (en supprimant le win32_ ) doit être émis pour chaque réponse ayant les propriétés dans le format par défaut et toutes les autres disponibles. Le progrès ne doit pas être utilisé.

Quelqu'un serait-il prêt à créer une courte RFC qui montre la syntaxe de l'applet de commande avec le format de sortie proposé pour examen?

@ stevel-msft je serais heureux de. :)

J'adore le son de ça.
Merci

C'est assez intéressant que le PR 3125 couvre tout cela, mais l'utilisation de Test-Connection a été rejetée, mais maintenant nous avons bouclé la boucle. Qu'en est-il du 3125?

En regardant brièvement, il semble qu'il a essentiellement remplacé Test-Connection par une commande mise en œuvre différemment sur les plates-formes Unix pour essayer d'émuler la commande Windows? Est-ce que je lis bien?

Je ne pense pas que ce soit la meilleure option qui s'offre à nous; la cohérence entre les deux plates-formes dans la mise en œuvre de la commande dans son ensemble est plus précieuse. Cela peut avoir des idées intéressantes que nous pouvons utiliser, j'en suis sûr!

Je déposerai un lien vers le projet de RFC lorsque j'aurai fini de l'écrire et n'hésitez pas à commenter, ajuster, etc. 🙂

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

Mon cas d'utilisation spécifique pour demander cela était basé sur le désir d'utiliser PowerShell Core sur Linux, mais l'implémentation a été entièrement testée sur Windows et Linux. Il était destiné à remplacer la commande manquante dans son intégralité.

Quand verrons-nous cela? Dans 6.2.2? Quand est-ce que cela atterrira probablement?
(C'était amusant de voir ce fil fait rage d'avril 2018 à maintenant plus _-calme__ étant bruyant. Cela semble un changement si simple)

Je peux écrire ce code assez facilement, je pense, j'attends juste que le RFC soit accepté. Dès que cela arrivera, je le ferai et soumettrai un PR pour cela. :sourire:

Oh, je pensais que le statut était qu'il a été approuvé (ne sachant pas exactement quels états il y a ou quel est le processus complet). Mais merci pour la mise à jour. Encore dommage qu'il ait fallu plus de 12 mois pour que ça se taise :)

plus de 12 mois pour le rendre calme

J'attendais plus de commentaires

@ vexx32, vous pouvez commencer à coder ceci et le placer derrière un indicateur expérimental au cas où des commentaires changeraient la proposition actuelle

@ SteveL-MSFT J'ai déjà une implémentation qui fonctionne principalement. Je chercherai bientôt à soumettre un PR avec quelques indicateurs expérimentaux afin que nous puissions parler du code plus concrètement. 💖

Après avoir réfléchi ces derniers jours au comportement souhaité, je préférerais avoir un comportement interactif avec un minimum de paramètres par défaut (saisie rapide et affichage convivial), ce qui serait pratique dans une session interactive. Et la conversion au style de script avec des paramètres supplémentaires (cela implique différents types en sortie).

Pourriez-vous expliquer un peu plus comment vous pensez que cela pourrait fonctionner @isazonov?

@ vexx32 Avez-vous des questions sur l'implémentation ou la conception UX?

Principalement ce que vous pensez que l'UX serait pour ça, je pense. :)

En session interactive, le meilleur UX est
1. frappe minimale
Ça veut dire:
- ping est par défaut
- passage à un autre mode (traceroute, etc.) avec un paramètre
2. sortie conviviale
Ça veut dire:
- émuler la sortie de ping.exe (tracert.exe et autres) _ sur l'hôte de la console_ comme j'ai essayé dans le code de démonstration - avec des en-têtes, des pieds de page et des lignes informatives bien formatées. Pas besoin de penser aux types de sortie - ils ne sont pas utilisés, seulement affichés.
- ajouter des paramètres pour passer en mode script - c'est-à-dire supprimer la sortie de texte convivial sur l'hôte de la console et émettre des objets typés forts. Pas besoin de formater cette sortie. Nous avons discuté de Quiet qui renvoie Vrai / Faux, mais nous avons besoin d'un ou de plusieurs paramètres pour émettre d'autres objets bruts typés forts (comme -RawOutput). Il est acceptable UX d'utiliser des paramètres supplémentaires dans les scripts.

Merci, je pense que je comprends ce que vous faites un peu mieux maintenant.

Je ne vois pas vraiment la nécessité d'un mode double comme celui-ci, cependant? Aucune autre applet de commande dans PowerShell n'a cette répartition entre les paramètres interactifs et "mode script".

Si vous vouliez la sortie exacte de ping / tracert, pourquoi ne pas utiliser ces utilitaires directement?

PowerShell n'a jamais fait un effort significatif pour imiter complètement une commande existante; Je pense que Get-ChildItem est probablement le plus proche, mais c'est presque le seul à le faire.

Si nous voulions émuler complètement l'affichage ping / tracert comme vous le dites, je suggérerais que nous l'ayons plutôt en tant que cmdlet ou fonction distincte, par exemple Show-Connection , plutôt que d'encombrer Show-Command avec des paramètres supplémentaires qui n'ont pas d'existence précédent ou besoin dans PowerShell.

Je ne vois pas vraiment la nécessité d'un mode double comme celui-ci, cependant? Aucune autre applet de commande dans PowerShell n'a cette répartition entre les paramètres interactifs et "mode script".

Nous avons des lacunes dans notre système de formatage. Par exemple, nous avons un problème avec la demande d'avoir un répertoire d'en-tête / pied de page. Il y a d'autres scénarios où cela serait pratique.

Si vous vouliez la sortie exacte de ping / tracert, pourquoi ne pas utiliser ces utilitaires directement?

Je fais :-). Ces utilitaires natifs sont très puissants car ils sont de bas niveau mais ils sont figés. Nous pouvons faire des choses plus merveilleuses qu'eux - c'est l'essence même de l'apparence de cette applet de commande (et pas seulement pour faire un ping) - si vous regardez en profondeur comment les adresses et les noms dans l'applet de commande sont maintenant formés et comment ils sont en sortie, vous verrez qu'il y a beaucoup plus utile que dans le ping natif. Cela ressemble à des astuces mais c'est vraiment très utile.

Bien sûr, nous avons des lacunes dans le système de formatage. Mais je ne pense pas que la réponse soit d'implémenter une solution personnalisée _ chaque fois_. Cela crée simplement plus de problèmes et rend encore plus difficile l'amélioration ou la réécriture du système de formatage pour être plus efficace à tous les niveaux.

Ouais, vous avez fait du bon travail avec! J'apprécie beaucoup cela. Le mode de sortie actuel n'est pas utile pour quoi que ce soit _ mais_ une utilisation interactive. Nous pourrions simplement supprimer l'étape de sortie et l'appeler Show-Connection , puis utiliser ce que vous avez écrit dans une solution plus axée sur PowerShell pour Test-Connection lui-même, comme je le décris dans la RFC.

@ vexx32 Je viens d'essayer votre PR et cela l'améliore un peu, mais j'ai remarqué que dans Windows PowerShell, il émet PingReply individuellement dans le pipeline afin que vous obteniez quelque chose qui ressemble à:

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

Cependant, avec votre modification, toutes les réponses ping sont membres d'un seul objet:

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…

Ne sommes-nous pas en mesure de rétablir le comportement de Windows PowerShell?

@ SteveL-MSFT La sortie de cet objet n'a pas changé depuis l'implémentation initiale dans PS Core; la sortie de succès a toujours eu un seul objet. 🙂

Comme mentionné dans les commentaires de clôture du PR, ce n'est qu'une mise en œuvre partielle de la RFC pour aider à simplifier les examens. Je vais soumettre un PR de suivi sous peu. Il suffit de rebaser cette branche pour supprimer les commits désormais dupliqués et de soumettre le reste pour se rapprocher beaucoup plus de la vraie parité avec l'implémentation de Windows PowerShell. Il différera encore quelque peu (comme on peut le voir dans le RFC que nous avons examiné il y a quelques semaines) mais il sera, espérons-le, beaucoup plus polyvalent. 😊

@ SteveL-MSFT voir # 10697 pour le prochain chapitre de cette aventure! 😊

: tada: Ce problème a été résolu dans # 10478, qui a maintenant été publié avec succès sous le nom v7.0.0-preview.5 .: tada:

Liens utiles:

• Notes de version

Dans la version 7.0.0 Test-Connection -Quiet donne toujours
Tester la connexion: échec du test de connexion à l'ordinateur «nettoyé»: impossible de résoudre le nom de la cible.
au lieu de
Faux

@chvol pourriez-vous s'il vous plaît ouvrir un nouveau numéro pour cela avec autant de détails que possible?

Merci! 🙂