これは5.1では正しく機能しますが、6では機能しないため、問題をバグとして再分類しました。

その理由は、現在のコードがWriteInformation （盲目的に？）呼び出すためです。

TestConnectionCommand.csの751行目、775行目と783行目

情報がホストに表示されないようにするための一時的な回避策は、 InformationAction共通パラメーターを使用することです。 例：

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

スクリプトの観点からは、これは問題にはなりません。テキスト情報がパイプラインにことはなく、テキスト出力は、パイプラインに送信されるものとして定義される結果データの一部ではQuietスイッチは、より単純な結果を返すように定義されています（レコードオブジェクトの代わりにintまたはbool ）。 Quiet InformationRecordを期待しないかもしれないことを認めなければなりません。 ただし、理由を知っていると、 InformationActionとQuiet分離しておく方がよいと思います。

PowerShell 5.1では、 Test-ConnectionはWriteInformationをまったく呼び出さないようです。 ちなみに、PowerShell5.1およびPowerShellCore 6.0.2の$InformationPreferenceのデフォルト値はSilentlyContinueです。 問題の作成者は、問題を再現したときに異なる有効値を持っている可能性があります。 （おそらくPS 6.1Coreが$InformationPreferenceのデフォルト値を変更しましたか？わかりません。）

PS 6.1 Coreのデフォルトの$InformationPreferenceがSilentlyContinue場合、ユーザーが明示的に要求しない限り、テキスト情報は表示されません。

もっとフィードバックが必要です。
問題は、スクリプトモードとインタラクティブモードでは、異なる方法で機能する必要があることです。 インタラクティブモードでは、ユーザーはping.exeコマンドで発生する進行状況（バー）を確認することを好むでしょう。 これは他のパラメータにも当てはまります。

@ mklement0時間があれば、あなたの助けが役に立ちます。

@GeeLaw ：

良い発見ですが、この場合、バグを回避するために必要なのは-InformationAction Ignoreです。

$InformationActionPreferenceはデフォルトでSilentlyContinueであり、変更しないでください。

バグは、 WriteInformation()がリンクを呼び出して、誤ってPSHOSTタグを使用することです。これにより、 $InformationActionPreference値と-InformationAction SilentlyContinueが効果的に_バイパス_されます（ただし、前述のとおり） 、 -InformationAction Ignore _is_出力の抑制に効果的です）。

WriteInformation()呼び出しが行うことは、事実上、その出力を（設計により）_無条件に_表示するためにWrite-Hostが行うことです。

@iSazonov ：プログレスバーを備えた他のコマンドレットの動作は実際には調べていませんが、 -Quietを使用すると、インタラクティブに呼び出した場合でも、プログレスバーを期待できません。

@ mklement0 PSHostTagの返信と修正に感謝します。 InformationPreference （ InformationAction ）はIgnore受け入れないようです。 これは5.1と6.0.2に当てはまります。 おそらく6.1で変更されました。 （IS InformationActionPreferenceのための新しいエイリアスInformationPreference ？）

また、私の最初のコメントは間違っていました。それは、 InformationActionをContinueです。 正しい回避策は、ストリーム6（情報ストリーム）を$nullにリダイレクトして破棄することです。つまり、

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

次の方法で正しいことを確認してください。

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

ホストには何も書き込まないはずです。

@GeeLaw ：

InformationPreference（InformationAction）は無視を受け入れないように思えますか？

はい、_preferencevariable_はIgnore受け入れませんが、_commonparameter_は受け入れます。

つまり、設計上、特定の呼び出しに対して情報ストリーム（番号6 ）を抑制できますが、スコープ全体に対しては_カテゴリ的に_抑制できません。

したがって、次の2つのステートメントは同等です。

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

言い換えると、 6> $nullと-InformationAction Ignore両方が効果的な回避策です。

あるInformationActionPreferenceのための新しいエイリアスInformationPreference ？

いいえ、名前は常に$InformationPreference 、 $VerbosePreference 、 $WarningPreference 、および$DebugPreferenceのパターンに従います。

私が知る限り、設定変数名がAction部分を保持しているのは、 -ErrorAction / $ErrorActionPreferenceペアだけです。

アクション_設定変数_の値としてのIgnoreの禁止に関する余談として：

• 高度な関数内で共通パラメーター値を伝播するために自動的に定義されたローカル設定変数が使用されるため、この制限には基本的な設計上の問題があります-＃1759を参照

• 制限は_割り当て時_には適用されません。つまり、次に設定が（おそらく暗黙的に）適用されるまで問題は発生しません。＃4348を参照してください。

  • より一般的には、グローバルスコープ以外のスコープでは、検証はまったく実行されません。 $ErrorActionPreference = 'bogus'と& { $ErrorActionPreference = 'bogus' }比較してください-参照してください
    

    3483。

@ mklement0あなたがInformationActionPreferenceと言ったので、私はエイリアスについて尋ねていました。

私の知る限り、 -XxxAction （および-Verboseと-Debug ）は、呼び出されたコマンドレット内に対応する設定変数を設定するだけです。 about_ヘルプトピックに記載されているように、具体的には次のとおりです。

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.

次のデモンストレーションで検証できるように、これをローカルプリファレンス変数の設定として解釈します。

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

5.1および6.0.2では、次のスニペットで示されているように、 InformationActionはIgnore受け入れません。

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

を生成します

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

6.1で変わったのかな。

もう1つの興味深い点があります。 $VerbosePreferenceと$DebugPreferenceは、対応する共通パラメーターで設定できる範囲よりも広い範囲を実際に受け入れます。 たとえば、明示的な割り当てによって$VerbosePreferenceをInquireに設定することは可能ですが、 -Verboseスイッチを使用することはできません。これは、結局のところ、スイッチであり、 $Trueをマップするためです。 $FalseからContinue / SilentlyContinue 。

私の知る限り、これら2つのスイッチを除いて、プリファレンス関連の共通パラメーターは、ローカルスコープ内の対応するプリファレンス変数に正確にマップされます。

遊んでみると、次のコードが機能することがわかります。

Write-Information 'writing' -InformationAction Ignore

しかし、チェック$InformationAction -eq 'Ignore'でWrite-Informationを保護し、そもそもそれを呼び出さないようにする必要があるため、開発者にとっては面倒です。

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

同じことがC＃でコマンドレットを書く作者にも当てはまるようです。

@GeeLaw

あなたがInformationActionPreferenceとしてそれを言及したので、私はエイリアスについて尋ねていました。

おっと！ 申し訳ありませんが、私自身のタイプミスに気づいていませんでした。

呼び出されたコマンドレット内に対応する設定変数を設定するだけです。

はい、そしてあなたが示す残りの部分は前述の＃1759の主題です。

つまり、設計上の欠陥は、設定変数値としてIgnoreを許可しないことは、共通パラメーター値を伝播するために自動的に設定されたローカル設定変数インスタンスを使用することと衝突することです。

すなわち：

5.1および6.0.2では、次のスニペットで示されているように、InformationActionは無視を受け入れません。

問題の解決に関して重要なので、 -InformationActionはIgnore受け入れますが、コンテキストで設定が適用された場合に問題を引き起こすのは設計上の欠陥だけであると指摘しておきます。 _高度な関数_の、あなたの場合はWrite-Informationが関数の_内部_を呼び出します。
この問題は、PowerShell Corev6.1.0-preview.2以降も引き続き発生します。

対照的に、_コンパイルされたコマンドレット_にはこの問題はありません。そのため、たとえば、発見してからWrite-Host foo -InformationAction Ignoreが意図したとおりに機能します。

要約すると、ここでは2つの無関係な問題について説明してきました。

• アクションプリファレンス変数値としてのIgnoreに関する設計上の欠陥。これは、＃1759ですでに追跡されています。

• この問題の元のトピック、不正な動作Test-Connection誤って使用するコマンドレット、 PSHOSTへの呼び出しでタグを.WriteInformation 。

後者の解決策は、次の例が示すように、単にタグを_省略_することです。

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

-Quietが尊重されていないという同じ問題が発生しているので、これに遭遇しました。 私はコードを見て、それが何をしているのかを理解するのが少し難しく、非常に複雑ですが、出力を抑制するために実際にこれを探している場所は見当たりませんでしたし、どこから切り替わっているのかもわかりません文字列をブール値に出力します。これは、-Quietパラメーターが渡されたときに出力されるはずです。

昨年、コードにTest-Connectionを追加するためのPR（＃2537）を提出しましたが、「@ PowerShell / powershell-committeeは、将来互換性の問題が発生するため、このPRを受け入れない」ため、その時点で拒否されました。そのため、このコマンドレットが含まれていることに驚きましたが、元のPRのコードではなく、期待されるすべての機能を提供しないまったく新しいコードが含まれています。

私が遭遇する最大の問題は、「if（Test-Connection 8.8.8.8 -Quiet）」のようなチェックを実行してロジックに分岐するスクリプトですが、-Quietパラメーターが尊重されない場合、分岐は常にTrueを返します。 FalseまたはNullがないためです。 そのため、このコマンドはまだ完全に使用できなくなります。また、PowerShellの新しいリリースに含まれているため、アップグレードが非常に簡単になります。 問題が最初に報告されてから数か月が経過しているように見えるので、これを修正してください。 それ、または元のPRを元に戻すことは、機能が返される限り重要ではありません。

昨年、コードにTest-Connectionを追加するためのPRを提出しましたが、レガシーコマンドレットを追加したくないため、その時点で拒否されました。そのため、このコマンドレットが含まれているのに、コードには含まれていないことに驚きました。完全で「レガシー」バージョンとまったく同じように機能した元のPRの

5.1と6.xにTest-Connectionがある場合、同じ出力になると思います。 実装が異なることは知っていますが、ユーザーはそれを気にする必要はありません。 6.1の現在のTest-Connectionの動作は異なり、5.1の場合とは異なる出力が得られます。 それに加えて、-Quietパラメータは実際には役に立ちません。

現在（PSVersion = 6.2.0）の時点で、この問題はまだ残っているようです。QUIETが存在する場合でも、コマンドレットは「ping」情報を表示し続けます（「-InformationActionIgnore」を追加するとうまくいきますが、モジュール/スクリプトがTest-Connectionコマンドレットは、クールではなく更新する必要があります）

これを7.0で修正できれば、本当に素晴らしいと思います。 コードを提供できてうれしいですが、これを改善するための以前の試みについてはほとんど合意がなかったため、従うべき実装仕様が必要です。

cc @ SteveL-MSFT @iSazonov

私は時々これに戻ります。 今では、 -Intercativeスイッチを使用した明示的な分離インタラクティブシナリオと非インタラクティブシナリオを使用することで、これを解決できると信じています。 このパラメーターを使用すると、ユーザーフレンドリーな豊富なコンソール出力を実装できます。 ユーザーがこのパラメーターを（「-i」として）入力するのはそれほど不便ではないようです。 スイッチがないと、スクリプトシナリオに適した、口頭でのコンソール出力なしで強い型の出力を実行できます。

他のコマンドレットがそのようなパラメーターを使用していないことを考えると、そのような二重性を持つことは意味がないと思います。 コマンドレットはそのタスクを実行し、一貫して動作する必要があります。 インタラクティブな振る舞いは、それ以外の振る舞いから分離されるべきではありません。

たとえば、Get-ChildItemを見てください。 インタラクティブに、デフォルトのフォーマッタ表示のおかげで非常に便利です。 自動化の目的にも役立つようにするために変更は必要ありません。 インタラクティブに機能する同じコマンドは、スクリプトでも機能します。

それは不必要な複雑さだと思います。

デフォルトでインタラクティブ出力を実行し、 Quietパラメーターを拡張して、スクリプトでの出力を抑制することができます。

繰り返しますが...インタラクティブとスクリプトで異なる出力を行う必要はないと思います。

コマンドレットが他のコマンドレットと同じように動作し、完全に一意でなく、すべてのデータをキャプチャまたは解析が困難なテキストストリーム（Bashではなく_PowerShell_）で出力するのではなく、使用できないデータを出力する場合、動作を変更する必要はまったくありません。 。

-Quietは、オブジェクトを出力する代わりに、純粋なTrue / False応答を提供するためにWindowsPowerShellの元のコマンドレットで使用されるスイッチです。 私の意見では、その慣習を破ることは悪い考えです。

このコマンドレットは、既存のコマンドレットと同じように動作する必要があります。 それだけで現在の動作を使用する理由はありません。 現在の反復では、他のPowerShellコマンドレットの動作方法とは大きく異なり、Unixユーティリティの動作を期待するとおりに動作します。

繰り返しますが...インタラクティブとスクリプトで異なる出力を行う必要はないと思います。

サポートされているすべてのシナリオで目的の出力をデモできますか？ コマンドレットが出力するメタ情報は非常に重要であることに注意してください。

キャプチャまたは解析が難しいテキストストリームにすべてのデータを出力する

コマンドレットは、強い型のオブジェクト出力を行います。 （問題は、「メタ」情報があるため、これらのオブジェクトを作成して同時に表示することができないことです。）

-Quietは、オブジェクトを出力する代わりに、純粋なTrue / False応答を提供するためにWindowsPowerShellの元のコマンドレットで使用されるスイッチです。 私の意見では、その慣習を破ることは悪い考えです。

そのWindowsPowerShellコマンドレットは、接続の概念が存在しないpingのみをサポートします。 これは当初、物議を醸した設計でした。 それらの正しい名前はTest-Ping ot Test-ICMPます。
現在のコマンドレットは、IP「接続」をサポートしています。 私は「テスト接続性」のようなものが好きですが。

現在の反復では、他のPowerShellコマンドレットの動作方法とは大きく異なり、Unixユーティリティの動作を期待するとおりに動作します。

いいえ、コマンドレットは強い型のオブジェクト出力を行います。 そして、コンソール出力はユーティリティのように見えるように作られました。 しかし同時に、実際にはそれがより豊かでより有用であることがわかるかもしれません。
問題は、この出力がフォーマットサブシステムの機能を使用して取得できず、コンソールに直接出力する必要があることです。 （これは、出力ストリーム内の出力オブジェクトと混同されないことに注意してください）

データオブジェクトをより堅牢な方法で構造化すると、フォーマットシステムを使用して出力を取得できます。 すでに試作品付きのPRを提出しました。 基になるオブジェクトデータを適切に反映しない形式でデータを表示するコマンドレット（たとえば、オブジェクトクラスを適切に構造化する代わりにサブプロパティからのデータを表示することによって）は、一般に誤解を招く可能性があり、可能な限り避ける必要があります。

これをさらに詳しく調べて、望ましい出力であると私が感じるもののより完全な例をまとめます。 Windows PowerShellでのテスト接続は物議を醸す設​​計だったかもしれませんが、非常に不完全なものであったとしても、それは正しい方向への一歩だったと思います。

@iSazonov最初に読んだ後、私はあなたに同意しませんでしたが、テストした後、私はあなたの視点を理解しています

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

$ aと$ bの値は私が期待するものですが、余分な出力は必要ありません。

Select-StringにはQuietパラメータもあり、「インタラクティブ」な動作とは何の関係もありません。

このコマンドが動作を変更するために追加のパラメーターを必要とすることに同意します（静かかどうか）。

私はデフォルトではなくパラメータ「インタラクティブ」を好みますが、おそらくスイッチパラメータ「NoInteractive」はインタラクティブな使用を優先するためのより良い調整です。

了解しました。これが、もう少し便利な実装だと私が考えるものです。

一般的なポイント

1. 現在のすべてのホスト/情報出力は-Verboseストリームに追いやられます。 現在、これはまったく使用されておらず、これは完璧なユースケースです。
2. -ShowProgressスイッチで指定しない限り、プログレスバーはありません。
3. -Pingスイッチを削除します（これがデフォルトの動作です）。

一次出力

Test-Connection www.google.com

• 出力オブジェクトのRepliesプロパティからの情報は、メイン出力オブジェクトに含まれている必要があり、プライマリ出力モードは、それぞれが単一のping試行/応答オブジェクトを表す_multiple_オブジェクトである必要があります。
• バッファ_data_は指定できないため、通常は関係ありません。また、 BufferSizeプロパティのみを公開する必要があります。 Replies.Bufferプロパティはprivateままにする必要があります。
• Replies.Optionsプロパティは、デフォルトのフォーマットから非表示にする必要があります。
• 結果は、宛先アドレスごとにグループ化されたテーブルとして出力されます（複数の宛先が指定されている場合）。

ビジュアルモックアップを出力

使用したコマンド：

$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

結果の出力：

   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

• 各ホップは個別のオブジェクトとして出力する必要があり、各ホップには、フォーマットから非表示にしてアクセスできるプロパティとしてPingReplyオブジェクトが含まれています。
• メインのTraceRouteResultオブジェクトには、4つのPingRepliesからサマリーデータを計算するETSまたはクラスプロパティが含まれている必要があります。
• 注：現在使用しているこのオブジェクトタイプにはPingReplyオブジェクトはステータスとしてTtlExpiredを報告します。 .NET Core 3の修正の進捗状況を調査するか、TraceRouteバッキングのカスタムソリューションを設計して問題を解決することをお勧めします。
• DestinationHostでグループ化されたテーブルとして出力します（このプロパティ名が、標準のpingに使用される他のオブジェクトタイプのプロパティ名と異なるのはなぜですか？）

ビジュアルモックアップを出力

使用したコマンド：

$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

結果の出力：

   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

私は、ユーザーにデータを提示する場合、画面に表示されているものと同様の表面構造で、プログラム的な方法でデータに簡単にアクセスできる必要があると確信しています。 プロパティの名前を変更したり、出力オブジェクトのプロパティの1〜2レベル深くデータを埋めたりすると、混乱、バグレポート、フラストレーション、および全体的なユーザビリティの大幅な低下を招くだけです。

ああ、 @ vexx32あなたはネットワークを診断したことがないようです。 あなたの提案は最初のステップで私によって実装され、その後、インタラクティブセッションでの使用に適していないとして却下されました。 たとえば、コマンドTest-Connection www.google.com -TraceRoute実行した後、非常に長い間空白の画面を見ることができます。 そのため、すべての応答の出力（文字列またはプログレスバー）を表示するように実装が変更されました。

現在のすべてのホスト/情報出力は、-Verboseストリームに追いやられます。 現在、それはまったく使用されておらず、これはその完璧なユースケースです。

上記の私の提案は、インタラクティブシナリオとスクリプトシナリオを分割するためのInteractiveスイッチを導入することVerboseスイッチでも同じことをすることをお勧めしますが、これはさらに不自然な方法です。

-ShowProgressスイッチで指定しない限り、プログレスバーはありません。

文字列出力とプログレスバーは、2つの選択肢として現在実装されています。 必要なのは1つだけです。 プログレスバーは、WindowsPowerShellコマンドレットで使用されます。 私の好みは、インタラクティブセッションでの文字列出力です。 それははるかに便利です。
また、スイッチでプログレスバーを抑制することはありません。 スクリプトシナリオ用の$ ProgressPreferenceがあります。 一部のコマンドレットには、タイマーによる長時間の操作に対してのみ進行状況バーが表示されます。

-Pingスイッチを削除します（これがデフォルトの動作です）。

ベストプラクティスは、スクリプトで明示的なパラメーターを使用することです。 コードが読みやすくなります。 pingのみが実装されているWindowsPowerShellコマンドレットでは必要ありませんでした。 新しいコマンドレットはより多くの機能を実装しており、すべての機能に新しい明示的なパラメーターが必要です。

あなたの提案は最初のステップで私によって実装され、その後、インタラクティブセッションでの使用に適していないとして却下されました。 たとえば、Test-Connection www.google.com -TraceRouteコマンドを実行した後、非常に長い間空白の画面を見ることができます。 そのため、すべての応答の出力（文字列またはプログレスバー）を表示するように実装が変更されました。

分割オブジェクト形式では、各オブジェクトが出力に送信されるときに進行状況を非常に簡単に確認できるため、進行状況の表示は必要ありません。 ここで必要な唯一の理由は、他のすべてのPowerShellコマンドレットのようにデータが取得されるため、パイプラインにデータを出力しないためです。 PingReplyごとに出力するか、 -TraceRouteトレースホップを実行すると、出力表示に進行状況表示が組み込まれます。

上記の私の提案は、インタラクティブスイッチを導入してインタラクティブシナリオとスクリプトシナリオを分割することでした。 さらに不自然な方法であるVerboseスイッチでも同じことを行うことをお勧めします。

-Verboseは一般的なパラメーターであるため、完全に新しいスイッチよりもはるかに自然なコマンドレットの選択です。 ここで車輪の再発明をする必要はありません。

ベストプラクティスは、スクリプトで明示的なパラメーターを使用することです。 コードが読みやすくなります。 pingのみが実装されているWindowsPowerShellコマンドレットでは必要ありませんでした。 新しいコマンドレットはより多くの機能を実装しており、すべての機能に新しい明示的なパラメーターが必要です。

私はここにもそこにもいませんが、通常、コマンドレットのデフォルトの動作にはスイッチがありません。 たとえば、 -Quiet逆の-Loudスイッチはありません。

分割オブジェクト形式では、各オブジェクトが出力に送信されるときに進行状況を非常に簡単に確認できるため、進行状況の表示は必要ありません。

上記の提案では、「ping」オブジェクトを「meta」オブジェクトに収集し、「ping」オブジェクトをリアルタイムで出力することはできません。パイプラインでは「meta」オブジェクトのみを出力できます。ユーザーには常に空白の表示が表示されます。

-Verboseは一般的なパラメーターであるため、完全に新しいスイッチよりもはるかに自然なコマンドレットの選択です。

詳細なストリームに重要な情報を出力していたコマンドレットを認識していません。 コマンドレットを実行するプロセスを理解できるように、常にこのストリームを使用して追加の診断情報を表示します。

通常、コマンドレットのデフォルトの動作にはスイッチがありません。

単一のパラメータセットに適しています。 これで多くのパラメータセットができたので、それぞれを明示的に指定する必要があります。

上記の提案では、「ping」オブジェクトを「meta」オブジェクトに収集し、「ping」オブジェクトをリアルタイムで出力することはできません。パイプラインでは「meta」オブジェクトのみを出力できます。ユーザーには常に空白の表示が表示されます。

メタオブジェクトは不要です。 上記の提案で述べたように、オブジェクトは_each_PingReplyまたはトレースホップ用に作成および出力されます。 モックアップは最終的なコードではなく、アイデアを説明するための簡単に複製できる形式です。 テーブルの各エントリは1つずつ出力されます。 提案全体をお読みください。

詳細なストリームに重要な情報を出力していたコマンドレットを認識していません。 コマンドレットを実行するプロセスを理解できるように、常にこのストリームを使用して追加の診断情報を表示します。

また、「重要な」情報を情報/ホストに定期的に出力し、別のオブジェクトの数レベル深く埋まっている場合を除いて出力しない_any_コマンドレットも認識していません。

単一のパラメータセットに適しています。 これで多くのパラメータセットができたので、それぞれを明示的に指定する必要があります。

そうすることにはあまり有用性はないと思いますが、それは私が思うに大きな害をもたらすことはありません。 時間の無駄だと思います。 多くの人がデフォルトの動作のスイッチを指定するのに多くの用途があるかどうかはわかりません。

メタオブジェクトは不要です。

_それは非常に必要です。_
このアプローチは、コマンドレットを役に立たないものにします。 問題のあるネットワークがある場合は、そのコマンドレットを使用して診断を実行してみてください。 これはできません。 それをスローし、pingおよびtracerouteユーティリティを使用します。 ただし、コンソールと、たとえば、スクリプトを使用した監視システムの両方で、新しいコマンドレットを使用して同じ診断を実行できるようになりました。 定期的なネットワーク診断を行わないと理解が難しいとのことですが。 特にUnixバージョンでは、これらのネイティブユーティリティが持つパラメータの数を確認してください。 それらはすべて診断にとって重要です。 診断の技術は、それらの組み合わせと魔法の意味を使用することにあります。 これらすべてを新しいコマンドレットに追加しようとしました。

時間の無駄だと思う

位置パラメータを使用すると、次のことに役立ちます:-)

PowerShell委員会の簡単な要約。

現在のコマンドレットは設計されました

• サポートされているすべてのプラットフォーム用のポータブルコマンドレットを取得します。 実際、.Net Coreにはまだいくつかの問題があるため、すべての機能がUnixプランフォームで機能するわけではありません。
• ping、traceroute、pathping、Portqry.exeなどの一般的なツールの機能を取得する
• 単純なネットワークアクセシビリティ分析と詳細なネットワークアクセシビリティ分析の両方に適した__scripts__の有用な出力オブジェクトを取得する
• _header_と_footer_で便利なコンソール出力を取得します。 一部のシナリオでは、コマンドレットにネイティブのプロトタイプユーティリティよりもさらに役立つ情報が表示されることに注意してください。
• リモートテスト「Test-Connection-Source ... -Destination ...」のような将来の拡張を可能にするため

主な問題は、インタラクティブコンソール出力（インタラクティブシナリオ）とパイプライン内のオブジェクトの出力（スクリプトシナリオ）をどのように組み合わせるかです。 私の現在の提案は、パラメーター（-Interactive）または新しいコマンドレット（インタラクティブシナリオの場合はShow-Connectivity、スクリプトシナリオの場合はTest-Connectivity）のいずれかを使用して分割を行うことです。
また、コマンドレットの名前をTest -__ Connectivity__に変更することをお勧めします。これはより正確です。 また、名前の競合なしに、プロキシ（WCM）を介して古いWindowsコマンドレットを無料で使用できるようになります。

@iSazonovは、すべてのデータを隠すメタオブジェクトが必要な診断の例を提供できますか？ 私の提案は、メタオブジェクトから各PingReplyオブジェクトに情報を移動することです。 それがコマンドレットの有用性をどのように低下​​させるかはわかりません。

作成直後にオブジェクトを出力する場合、フッターから最初の「ping」オブジェクトに統計をどのように配置しますか？

どのようなフッター情報ですか？ pingからの唯一のフッター情報はPing complete.

現在のメタオブジェクトには、どこでも見ることができる統計はありません。 それらには、情報ストリーム上で文字列データとしてレンダリングされているのと同じ情報を持つすべてのオブジェクトが、使いにくい形式で含まれているだけです。

ここでのポイントは、両方のバージョン（WinPSとPwsh）でコマンドレット（この場合はTest-Connection）を同じ方法で維持し、この場合はコマンドレットにスイッチを追加して、出力が間違っていることを「無効にする」ことです。このコマンドレットを使用するすべてのスクリプト/モジュールを更新する必要があることを意味する前に、ソリューションは両方のバージョンで同じ方法でそれを作成しています

@ NJ-Dude WindowsコマンドレットはWMIに基づいており、下位互換性を持って移植することはできません。 また、5.1は凍結されました-将来追加されることはありません。

@ NJ-Dude WindowsコマンドレットはWMIに基づいており、下位互換性を持って移植することはできません。 また、5.1は凍結されました-将来追加されることはありません。

構文と機能は同じである必要があることを理解し、知っています。つまり、QUIETを使用しても出力が表示されない場合は、使用されているPSのフレーバーに関係なく出力が表示されないはずです。

構文と機能は同じである必要があると言っているだけです

それは不可能です。 Windows互換性モジュールは、古い機能を取得するための1つの方法です。

コマンドレットの出力は、メイン出力とは別のコンソールへの不要な表示を手動で抑制することなく、保存して使用できる必要があります。

このように動作するコマンドレットは他にありません。最も有用なデータは情報ストリーム上の文字列形式です。 このように動作する理由はありません。 すべてのデータは、出力ストリーム期間にある必要があります。 追加のデータは、必要に応じて詳細ストリームまたはデバッグストリームにあります。 この方法での情報ストリームの使用は、PowerShell自体に付属するコマンドレットでは文字通り前例のないものです。

また、前述のように、フッターには特にフッターに含める必要のあるデータはありません。 すべて最初から、または各応答が処理されるときに利用できます。

委員会の議論のためにこれを待ち行列に入れる

Soooo私はここで少しスレッドを見失い、雑草に問題がありましたが、実装に関係なく私の基本的な見解はこれです：

• データは1行ずつ出力する必要があります。 Test-Connectionとping.exeなどの両方の現在のケースだと思います
• データは構造化オブジェクトとして返される必要があります。 フォーマットはこの事実にとらわれないはずです。 （これは恐ろしいことですが、内部ではPSObjectであるにもかかわらず、コンソールにJSON文字列を出力するフォーマッターを見てきました。私のポイントは単にそれができるということです。）フォーマットは私たちが行う場所でもあります。 '変更を壊すことなく、必要なものを変更できます。 （ @ vexx32にも強く同意します。プロパティ名と一致しない列ヘッダーに注意する必要があります。読みやすくするために必要な場合もありますが、気が狂います。）
• -Quietは、Windows PowerShellと同様に、ブール値としてTrue / False以外は何も出力しないはずです。
• デフォルトの場合（最小ブール値の-Quiet場合よりも多いはずです）よりも多くの情報を出力する必要がある場合、 -Verboseは妥当に聞こえますが、十分に考えていません。 （これは私がスレッドを失う場所でもあり、他の人々が上で何を望んでいるのかを知るのは難しいです）。
• Windows PowerShellとまったく同じプロパティ（.NET Core、WMIなど）を使用してまったく同じオブジェクト（ cimv2\Win32_PingStatus ）を模倣することは不可能ですが、可能な限り近づけるように努める必要があります。
• 進捗状況はわかりません。 私のハイレベルな見解は、進歩は遅いので（最適化にもかかわらず）まだみんなを夢中にさせるだけでなく、とにかくみんなが$ProgressPreference設定しているので、非インタラクティブではそれほど重要ではないということです。

私にはいいですね！

進行状況は、コマンド呼び出しでは処理できないため、主に私を悩ませます。 $ ProgressPreferenceを設定する必要があります。 それが共通のパラメータであることを本当に望んでいます...しかし、私はそれについて別の問題を抱えているので、ここではそれについては触れません！ ：スマイル：

@ PowerShell / powershell-委員会がこれをレビューしました。 Test-Connectionは、Windows PowerShell 5.1の場合と同じように動作を可能な限りエミュレートする必要があることに同意しました（ -Quiet ）。 これは、デフォルト形式のプロパティと使用可能な追加のプロパティを持つ応答ごとに、 PingStatus出力オブジェクト（ win32_を削除）を発行する必要があることを意味します。 Progressは使用しないでください。

誰かが、レビューのために提案された出力形式とともにコマンドレット構文を示す短いRFCを作成することをいとわないでしょうか？

@ stevel-msftよろしくお願いします。 :)

私はその音が大好きです。
ありがとう

PR 3125がこれらすべてをカバーしているのは興味深いことですが、Test-Connectionの使用は拒否されましたが、今では完全に一巡しています。 3125を振り返ってみませんか？

簡単に見てみると、Windowsコマンドをエミュレートしようとするために、基本的にTest-ConnectionをUnixプラットフォームで別の方法で実装されたコマンドに置き換えたように見えますか？ 私はその権利を読んでいますか？

それが私たちが利用できる最善の選択肢ではないと思います。 コマンド全体の実装における両方のプラットフォーム間の一貫性は、より価値があります。 でも、面白いアイデアがあるかもしれませんが、きっと！

RFCのドラフトを書き終えたら、リンクをドロップします。コメントや調整などを自由に行ってください。これについて、さらにいくつかの視点を聞きたいと思います。 🙂

編集： https ：

これを促すための私の特定の使用例は、LinuxでPowerShell Coreを使用したいという願望に基づいていましたが、実装はWindowsとLinuxの両方で完全にテストされました。 これは、欠落しているコマンド全体を置き換えることを目的としていました。

これはいつ見られますか？ 6.2.2では？ それはいつ着陸する可能性がありますか？
（このスレッドが2018年4月から今まで_-静かな_騒々しいことで激怒したのを見るのは面白かったです。そのような簡単な破壊的な変化のようです）

私はこのコードをかなり簡単に書くことができると思います。RFCが受け入れられるのを待っているだけです。 それが起こったらすぐに私はそれを成し遂げて、これのためにPRを提出します。 ：スマイル：

ああ、私はそれが承認されたというステータスだと思いました（どのような状態があるのか​​、または完全なプロセスが何であるのか正確にはわかりません）。 しかし、アップデートに感謝します。 それでも静かにするのに12ヶ月以上かかったのは残念です:)

静かにするために12ヶ月以上

私はより多くのフィードバックを期待していました

@ vexx32これをコーディングし始めて、現在の提案を変更するフィードバックが入った場合に備えて、実験フラグの後ろに置くことができます

@ SteveL-MSFT私はすでにほとんど機能する実装を持っています。 コードについてより具体的に話すことができるように、すぐにいくつかの実験フラグ付きのPRを提出する予定です。 💖

昨日、望ましい動作について考えた後、デフォルトで最小限のパラメーター（高速入力とユーザーフレンドリーな表示）を使用した対話型の動作を希望します。これは、対話型セッションで便利です。 そして、追加のパラメーターを使用してスクリプトスタイルに変換します（これは、出力のタイプが異なることを意味します）。

@isazonovがどのように機能すると思うかについてもう少し詳しく説明していただけますか？

@ vexx32実装やUXデザインについて質問しますか？

主に、UXはそのためにどのようになると思いますか。 :)

インタラクティブセッションでは、最高のUXは
1.最小限のタイピング
その意味は：
-pingがデフォルトです
-1つのパラメータで別のモード（tracerouteなど）に切り替える
2.ユーザーフレンドリーな出力
その意味は：
-デモコードで試したように、ping.exe（tracert.exeなど）の出力をコンソールホストでエミュレートします。ヘッダー、フッター、情報行を適切にフォーマットします。 出力タイプについて考える必要はありません-それらは使用されず、表示されるだけです。
-スクリプトモードに切り替えるパラメータを追加します-つまり、コンソールホストでのユーザーフレンドリーなテキストの出力を抑制し、強い型のオブジェクトを出力します。 この出力をフォーマットする必要はありません。 True / Falseを返すQuietについて説明しましたが、他の強い型のオブジェクト（-RawOutputなど）を出力するためのパラメーターが必要です。 スクリプトで追加のパラメーターを使用することは、UXで許容されます。

おかげで、私はあなたが今少し良くなっていることを理解していると思います。

しかし、私はこのようなデュアルモードの必要性を実際には見ていませんか？ PowerShellの他のコマンドレットには、インタラクティブパラメーターと「スクリプトモード」パラメーターの間でこの分割がありません。

ping / tracertの正確な出力が必要な場合は、これらのユーティリティを直接使用しないのはなぜですか？

PowerShellは、既存のコマンドを完全に模倣するために多大な努力をしたことはありません。 Get-ChildItemがおそらく最も近いと思いますが、そうするのはほぼ唯一です。

あなたが言うようにping / tracertの表示を完全にエミュレートしたい場合は、既存のない追加のパラメーターを使用してShow-Commandを乱雑にするのではなく、代わりに別のコマンドレットまたは関数として使用することをお勧めします（例： Show-Connection ）。 PowerShell内の前例または必要性。

しかし、私はこのようなデュアルモードの必要性を実際には見ていませんか？ PowerShellの他のコマンドレットには、インタラクティブパラメーターと「スクリプトモード」パラメーターの間でこの分割がありません。

アウトフォーマットシステムにギャップがあります。 たとえば、ヘッダー/フッターディレクトリのリクエストに問題があります。 それが便利である他のシナリオがあります。

ping / tracertの正確な出力が必要な場合は、これらのユーティリティを直接使用しないのはなぜですか？

私がやります ：-）。 これらのネイティブユーティリティは低レベルであるため非常に強力ですが、フリーズしています。 コマンドレット内のアドレスと名前がどのように形成されているか、およびそれらがどのように形成されているかを詳しく調べると、これがこのコマンドレットの外観の本質です（pingを実行するだけではありません）。が出力されると、ネイティブpingよりもはるかに便利であることがわかります。 トリックのように見えますが、とても便利です。

もちろん、フォーマットシステムにはギャップがあります。 しかし、その答えは、カスタムソリューションを_毎回_実装することではないと思います。 それは単に問題をさらに引き起こし、フォーマットシステムを改善または書き直して全体的に効果的にすることをさらに困難にします。

ええ、あなたはそれでいくつかの素晴らしい仕事をしました！ とても感謝しています。 現在の出力モードは、インタラクティブな使用には役立ちません。 出力ステップを削除してShow-Connectionと呼ぶだけで、RFCで概説しているように、PowerShellに焦点を当てたソリューションで記述したものをTest-Connection自体に利用できます。

@ vexx32 PRを試したところ、かなり改善されましたが、Windows PowerShellでは、PingReplyがパイプラインに個別に送信されるため、次のようになります。

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

ただし、変更を加えると、すべてのping応答は単一のオブジェクトのメンバーになります。

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…

Windows PowerShellの動作を元に戻すことはできませんか？

@ SteveL-MSFTそのオブジェクト出力はPSCoreの最初の実装から変更されていません。 成功の出力には常に単一のオブジェクトが含まれていました。 🙂

PRの最後のコメントで述べたように、これはレビューを簡素化するためのRFCの途中的な実装にすぎません。 間もなくフォローアップPRを提出します。 そのブランチをリベースして、重複しているコミットを削除し、残りを送信して、WindowsPowerShellの実装との真の同等性にさらに近づける必要があります。 それでも多少異なりますが（数週間前にレビューしたRFCからわかるように）、もっと用途が広いことを願っています。 😊

@ SteveL-MSFTは、この冒険の次の章については＃10697を参照してください。 😊

： tada：この問題は＃10478で解決され、 v7.0.0-preview.5として正常にリリースされました。：tada：

便利なリンク：

• リリースノート

リリース7.0.0ではTest-Connection-Quietはまだ
テスト接続：コンピューター「スクラブ」への接続のテストに失敗しました：ターゲット名を解決できません。
の代わりに
誤り

@chvol可能な限り詳細に、そのための新しい問題を開いて

ありがとう！ 🙂