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 를 전혀 호출하지 않는 것 같습니다. 그런데 PowerShell 5.1 및 PowerShell Core 6.0.2에서 $InformationPreference 의 기본값은 SilentlyContinue 입니다. 문제의 저자는 문제를 재현 할 때 다른 유효 가치를 가질 수 있습니다. (아마도 PS 6.1 Core가 $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 : 진행률 표시 줄이있는 다른 cmdlet의 동작을 실제로 살펴 -Quiet 를 사용하면 대화 형으로 호출 할 때도 진행률 표시 줄을 기대하지 _ 않습니다

@ mklement0 PSHostTag 에 대한 답장과 수정에 감사드립니다. InformationPreference ( InformationAction )이 (가) Ignore 수락하지 않는 것 같습니다. 이것은 5.1과 6.0.2에서 사실입니다. 아마도 6.1에서는 변경되었습니다. (사 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)가 Ignore를 수락하지 않는 것 같습니다.

예, _preference 변수 _는 Ignore 허용하지 않지만 _common parameter_는 허용합니다.

즉, 주어진 호출에 대해 정보 스트림 (번호 6 ) _을 억제 할 수 있지만 _ 전체 범위에 대해서는 _ 범주 적으로 _ 설계 할 수 없습니다.

따라서 다음 두 문은 동일합니다.

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 ?

아니요, 이름은 $VerbosePreference , $WarningPreference 및 $DebugPreference 패턴에 따라 항상 $InformationPreference $DebugPreference 입니다.

내가 알 수있는 바는 -ErrorAction / $ErrorActionPreference 쌍 뿐이며 환경 설정 변수 이름은 Action 부분을 ​​유지합니다.

행동 _preference variables_의 값으로 Ignore 의 금지와 관련하여 추가로 :

• 이 제한에는 근본적인 설계 문제가 있습니다. 자동으로 정의 된 로컬 기본 설정 변수가 고급 함수 내에서 공통 매개 변수 값을 전파하는 데 사용되기 때문입니다. # 1759 참조

• 제한은 _ 할당 시간 _에 적용되지 않습니다. 즉, 다음에 환경 설정이 (암시 적으로) 적용될 때까지 문제가 표시되지 않습니다. # 4348 참조

  • 보다 일반적으로 전역 범위를 제외한 모든 범위에서 유효성 검사가 전혀 수행되지 않습니다. $ErrorActionPreference = 'bogus' 와 & { $ErrorActionPreference = 'bogus' } -참조
    

    3483.

@ mklement0 InformationActionPreference 로 언급했기 때문에 별칭에 대해 질문했습니다.

내가 아는 한 -XxxAction (및 -Verbose 및 -Debug )는 단순히 호출 된 cmdlet 내에서 해당 기본 설정 변수를 설정합니다. 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에서 변경되었는지 궁금합니다.

또 다른 흥미로운 점이 있습니다. $VerbosePreference 및 $DebugPreference 실제로 해당하는 공통 매개 변수로 설정할 수있는 것보다 더 넓은 범위를 허용합니다. 예를 들어, 명시 적 할당으로 $VerbosePreference 를 Inquire 로 설정할 수 있지만 -Verbose 스위치를 사용하면 불가능합니다. 결국 스위치이고 $True 매핑하기 때문입니다. $False ~ Continue / SilentlyContinue .

내가 아는 한이 두 스위치를 제외하고 기본 설정 관련 공통 매개 변수는 로컬 범위의 해당 기본 설정 변수에 정확히 매핑됩니다.

또 다른 작업은 다음 코드가 작동하는 것을 보여줍니다.

Write-Information 'writing' -InformationAction Ignore

우리가 보호해야하지만 즉, 개발자들에게 성가신 일 것입니다 Write-Information 로 확인 $InformationAction -eq 'Ignore' , 그리고 피할 예를 들어, 처음에 전화,

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 #으로 cmdlet을 작성하는 작성자에게도 동일하게 적용되는 것 같습니다.

헉

나는 당신이 그것을 InformationActionPreference로 언급했기 때문에 별칭에 대해 묻고 있었다.

이런! 미안합니다-내 오타를 알아 차리지 못했습니다.

호출 된 cmdlet 내에 해당 기본 설정 변수를 설정하기 만하면됩니다.

예, 당신이 보여주는 나머지 부분은 앞서 언급 한 # 1759의 주제입니다.

요컨대 : 디자인 결함은 Ignore 를 기본 설정 변수 값으로 허용하지 않는 것이 공통 매개 변수 값을 전파하기 위해 자동으로 설정된 로컬 기본 설정 변수 인스턴스를 사용하는 것과 충돌한다는 것입니다.

더 구체적으로:

5.1 및 6.0.2에서 InformationAction은 다음 스 니펫에서 알 수 있듯이 무시를 허용하지 않습니다.

문제 해결과 관련하여 중요하므로 -InformationAction _does_ accept Ignore 지적하겠습니다. 문제를 일으키는 디자인 결함은 _if 및 환경 설정이 적용될 때 _ 컨텍스트에서 귀하의 경우 Write-Information call _inside_ the function _advanced functions_의.
이 문제는 PowerShell Core v6.1.0-preview.2부터 지속됩니다.

대조적으로 _Compiled cmdlets_에는이 문제가 없습니다. 따라서 Write-Host foo -InformationAction Ignore 가 의도 한대로 작동합니다.

요약하면, 우리는 여기서 두 가지 관련되지 않은 문제를 논의했습니다.

• 액션 선호 변수 값으로 Ignore 대한 디자인 결함은 이미 # 1759에서 추적되고 있습니다.

• 이 문제의 원래 주제의 오작동 Test-Connection 잘못 사용 cmdlet을, PSHOST 에의 호출에 태그를 .WriteInformation .

후자에 대한 해결책은 다음 예제에서 보여 주듯이 태그를 간단히 _omit_하는 것입니다.

# 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을 수락하지 않을 것"이므로 당시 거부되었습니다. 그래서 지금은이 cmdlet이 포함되어 있지만 원래 PR의 코드가 아니라 예상되는 모든 기능을 제공하지 않는 완전히 새로운 코드를보고 놀랐습니다.

내가 접한 가장 큰 문제는 스크립트에서 "if (Test-Connection 8.8.8.8 -Quiet)"와 같은 검사를 수행하여 로직으로 분기하지만 -Quiet 매개 변수가 존중되지 않으면 분기가 항상 True를 반환한다는 것입니다. False 또는 Null이 없기 때문입니다. 따라서이 명령은 여전히 ​​나에게 완전히 사용할 수 없게 만들고 PowerShell의 새 릴리스에 포함 되었기 때문에 업그레이드가 매우 간편합니다. 문제가 처음보고 된 후 몇 달이 지난 것처럼 보이므로이 문제를 수정하세요. 기능이 반환되는 한 그 중 하나 또는 원래 PR을 복원하는 것은 중요하지 않습니다.

작년에 코드에 Test-Connection을 추가하기 위해 PR을 제출했는데 레거시 cmdlet을 추가하지 않기를 원했기 때문에 당시 거부되었으므로 지금은이 cmdlet이 포함되어 있지만 코드에는 포함되지 않은 것을보고 놀랐습니다. 완전하고 "레거시"버전과 똑같은 기능을하는 원래 PR의.

5.1과 6.x에 Test-Connection이 있으면 동일한 출력을 가질 것으로 예상합니다. 구현이 다르다는 것을 알고 있지만 사용자는 그것에 대해 신경 쓰지 않아야합니다. 6.1의 현재 Test-Connection은 다르게 동작하여 5.1에서와 다른 출력을 제공합니다. 게다가 -Quiet 매개 변수는 사실상 쓸모가 없습니다.

현재 (PSVersion = 6.2.0) 현재 (PSVersion = 6.2.0) cmdlet은 QUIET이 있어도 계속해서 "ping"정보를 표시합니다 ( "-InformationAction Ignore"를 추가하면 트릭을 수행하지만 모듈 / 스크립트가 Test-Connection cmdlet을 업데이트해야합니다.

7.0에서이 문제를 해결할 수 있다면 정말 좋을 것입니다. 나는 코드를 기여하게되어 기쁘지만,이를 개선하려는 초기 시도에 대한 동의가 거의 없었기 때문에 따라야 할 구현 사양이 필요합니다.

cc @ SteveL-MSFT @iSazonov

나는 때때로 이것으로 돌아온다. 이제 -Intercative 스위치를 사용하여 대화 형 및 비대화 형 시나리오를 명시 적으로 분리하여이 문제를 해결할 수 있다고 생각합니다. 매개 변수를 사용하여 사용자 친화적 인 풍부한 콘솔 출력을 구현할 수 있습니다. 사용자가이 매개 변수 ( "-i"로)를 입력하는 것이 너무 불편하지 않은 것 같습니다. 스위치가 없으면 스크립트 시나리오에 적합한 자세한 콘솔 출력없이 강력한 형식의 출력을 수행합니다.

다른 cmdlet에서 이러한 매개 변수를 사용하지 않는다는 점을 감안할 때 이러한 이중성을 갖는 것은 의미가 없다고 생각합니다. cmdlet은 작업을 수행하고 일관되게 작동해야합니다. 대화 형 동작은 다른 방식으로 동작하는 방식과 분리되어서는 안됩니다.

예를 들어 Get-ChildItem을 살펴보십시오. 대화식으로는 기본 포맷터 디스플레이 덕분에 매우 유용합니다. 자동화 목적으로도 유용하게 만들기 위해 변경할 필요가 없습니다. 대화식으로 작동하는 동일한 명령이 스크립트에서도 작동합니다.

그것은 불필요한 복잡성입니다.

기본적으로 대화 형 출력을 수행하고 Quiet 매개 변수를 향상시켜 스크립트에서 출력을 억제 할 수 있습니다.

다시 말하지만 ... 나는 스크립트와 대화식으로 다른 출력을 가질 필요가 없다고 생각합니다.

cmdlet이 단순히 다른 cmdlet처럼 작동하고 완전히 고유하지 않고 사용할 수없는 데이터를 출력하고 모든 데이터를 캡처하거나 구문 분석하기 어려운 텍스트 스트림 (Bash가 아닌 _PowerShell_)으로 출력하는 경우 동작을 변경할 필요가 전혀 없습니다. .

-Quiet는 Windows PowerShell의 원래 cmdlet에서 개체를 출력하는 대신 순수한 True / False 응답을 제공하는 데 사용하는 스위치입니다. 그 관습을 깨는 것은 제 생각에 나쁜 생각입니다.

이 cmdlet은 기존 cmdlet과 일관된 방식으로 작동해야합니다. 현재 동작을 단독으로 사용할 이유가 없습니다. 현재 반복에서는 다른 PowerShell cmdlet이 작동하는 방식과 매우 다른 Unix 유틸리티가 작동 할 것으로 예상하는 것처럼 더 많이 작동합니다.

다시 말하지만 ... 나는 스크립트와 대화식으로 다른 출력을 가질 필요가 없다고 생각합니다.

지원되는 모든 시나리오에서 원하는 출력을 데모 할 수 있습니까? cmdlet이 출력하는 메타 정보는 매우 중요합니다.

텍스트 스트림을 캡처하거나 구문 분석하기 어려운 모든 데이터를 출력

cmdlet은 강력한 형식의 개체 출력을 수행합니다. (문제는 "메타"정보가 있기 때문에 이러한 개체를 만들고 동시에 표시하는 것이 불가능하다는 것입니다.)

-Quiet는 Windows PowerShell의 원래 cmdlet에서 개체를 출력하는 대신 순수한 True / False 응답을 제공하는 데 사용하는 스위치입니다. 그 관습을 깨는 것은 제 생각에 나쁜 생각입니다.

해당 Windows PowerShell cmdlet은 연결 개념이없는 ping 만 지원합니다. 이것은 처음에는 논란의 여지가있는 디자인이었습니다. 올바른 이름은 Test-Ping ot Test-ICMP 입니다.
현재 cmdlet은 ip "연결"을 지원합니다. "Test-Connectivity"와 같은 것을 선호하지만.

현재 반복에서는 다른 PowerShell cmdlet이 작동하는 방식과 매우 다른 Unix 유틸리티가 작동 할 것으로 예상하는 것처럼 더 많이 작동합니다.

아니요, cmdlet은 강력한 형식의 개체 출력을 수행합니다. 그리고 콘솔 출력은 유틸리티처럼 보이도록 만들어졌습니다. 그러나 동시에 실제로 더 풍부하고 유용하다는 것을 알 수 있습니다.
문제는 포맷팅 서브 시스템의 기능을 사용하여이 출력을 얻을 수 없으며 콘솔에 직접 출력해야한다는 것입니다. (이것은 출력 스트림의 출력 객체와 혼동되지 않습니다.)

데이터 개체를보다 강력한 방식으로 구조화하면 형식화 시스템으로 출력을 얻을 수 있습니다. 이미 프로토 타입으로 PR을 제출했습니다. 기본 개체 데이터를 제대로 반영하지 않는 형식으로 데이터를 표시하는 cmdlet (예 : 개체 클래스를 적절하게 구성하는 대신 하위 속성의 데이터 표시)은 일반적으로 오해의 소지가 있으며 가능한 한 피하는 것이 좋습니다.

나는 이것을 더 조사하고 내가 원하는 결과물이라고 생각하는 것에 대한 더 완전한 예를 모을 것입니다. Windows PowerShell의 Test-Connection은 논란의 여지가있는 디자인 일 수 있지만, 매우 불완전한 경우라면 올바른 방향으로 나아가는 단계라고 생각합니다.

@iSazonov 처음 읽은 후 동의하지 않았지만 테스트 후 귀하의 관점을 이해합니다.

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

$ a 및 $ b 값은 내가 기대하는 값이지만 추가 출력을 원하지 않습니다.

Select-String 에는 또한 Quiet 매개 변수가 있으며 "대화 형"동작과 관련이 없습니다.

이 명령에는 동작을 변경하기 위해 추가 매개 변수가 필요하다는 데 동의합니다 (조용 여부).

나는 기본적으로 매개 변수 'Interactive'를 선호하지만, 아마도 스위치 매개 변수 "NoInteractive"는 대화식 사용에 우선 순위를두기 위해 더 나은 조정일 것입니다.

좋아, 여기에 좀 더 유용한 구현이라고 생각하는 것이 있습니다.

일반 포인트

1. 모든 현재 호스트 / 정보 출력은 -Verbose 스트림으로 강등됩니다. 현재는 전혀 사용되지 않으며 완벽한 사용 사례입니다.
2. -ShowProgress 스위치로 지정하지 않으면 진행률 표시 줄이 없습니다.
3. -Ping 스위치를 제거합니다 (기본 동작).

1 차 출력

Test-Connection www.google.com

• 출력 개체의 Replies 속성 정보는 기본 출력 개체에 포함되어야하며 기본 출력 모드는 각각 단일 핑 시도 / 응답 개체를 나타내는 _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 스위치로 지정하지 않으면 진행률 표시 줄이 없습니다.

문자열 출력 및 진행률 표시 줄은 두 가지 대안으로 현재 구현 중입니다. 하나만 필요합니다. 진행률 표시 줄은 Windows PowerShell cmdlet에서 사용됩니다. 내 선호는 대화식 세션의 문자열 출력입니다. 훨씬 더 편리합니다.
그리고 우리는 스위치로 진행률 표시 줄을 억제하지 않습니다. 스크립트 시나리오를위한 $ ProgressPreference가 있습니다. 일부 cmdlet은 타이머에 의한 긴 작업에 대해서만 진행률 표시 줄을 표시합니다.

-Ping 스위치를 제거합니다 (기본 동작).

모범 사례는 스크립트에서 명시 적 매개 변수를 사용하는 것입니다. 코드를 더 읽기 쉽게 만듭니다. ping 만 구현 된 Windows PowerShell cmdlet에서는 필요하지 않았습니다. 새로운 cmdlet은 더 많은 기능을 구현하며 모든 기능에 대해 새로운 명시 적 매개 변수가 필요합니다.

귀하의 제안은 첫 번째 단계에서 저에 의해 구현되었으며 대화 형 세션에서 사용하기에 적합하지 않은 것으로 거부되었습니다. 예를 들어, Test-Connection www.google.com -TraceRoute 명령을 실행 한 후 오랫동안 빈 ​​화면을 볼 수 있습니다. 따라서 모든 응답에 대한 출력 (문자열 또는 진행률 표시 줄)을 표시하도록 구현이 변경되었습니다.

각 개체가 출력에 제출 될 때 진행 상황을 매우 쉽게 볼 수 있으므로 분할 개체 형식에서는 진행률 표시가 필요하지 않습니다. 여기서 필요한 유일한 이유는 다른 모든 PowerShell cmdlet이 수행하는 것처럼 데이터가 검색 될 때 파이프 라인에 데이터를 출력하지 않기 때문입니다. PingReply 마다 출력하거나 -TraceRoute 대한 추적 홉을 출력하면 출력 디스플레이에 진행률 표시가 _have_됩니다.

위의 제안은 대화 형 및 스크립트 시나리오를 분할하는 대화 형 스위치를 도입하는 것입니다. 훨씬 더 부 자연스러운 연습 인 Verbose 스위치로 동일한 작업을 수행하는 것이 좋습니다.

-Verbose 는 일반적인 매개 변수이므로 완전히 새로운 스위치보다 훨씬 자연스러운 cmdlet 선택입니다. 여기서 바퀴를 재발 명 할 필요는 없습니다.

모범 사례는 스크립트에서 명시 적 매개 변수를 사용하는 것입니다. 코드를 더 읽기 쉽게 만듭니다. ping 만 구현 된 Windows PowerShell cmdlet에서는 필요하지 않았습니다. 새로운 cmdlet은 더 많은 기능을 구현하며 모든 기능에 대해 새로운 명시 적 매개 변수가 필요합니다.

나는 여기도 거기에 있지 않지만 일반적으로 cmdlet의 기본 동작에는 스위치가 없습니다. 예를 들어 -Quiet 의 반대 인 -Loud 스위치가 없습니다.

각 개체가 출력에 제출 될 때 진행 상황을 매우 쉽게 볼 수 있으므로 분할 개체 형식에서는 진행률 표시가 필요하지 않습니다.

위의 제안을 통해 우리는 "meta"객체에서 "ping"객체를 수집하고 "ping"객체를 실시간으로 출력하는 것은 불가능합니다. 파이프 라인에서 "meta"객체 만 출력 할 수 있습니다. 사용자는 항상 빈 화면을 보게됩니다.

-Verbose는 일반적인 매개 변수이므로 완전히 새로운 스위치보다 훨씬 자연스러운 cmdlet 선택입니다.

자세한 정보 스트림에 중요한 정보를 출력하는 cmdlet을 알지 못합니다. cmdlet 실행 프로세스를 이해할 수 있도록 항상이 스트림을 사용하여 추가 진단 정보를 표시합니다.

일반적으로 cmdlet의 기본 동작에는 스위치가 없습니다.

단일 매개 변수 세트에 적합합니다. 이제 많은 매개 변수 세트가 있으며 각각을 명시 적으로 지정해야합니다.

위의 제안을 통해 우리는 "meta"객체에서 "ping"객체를 수집하고 "ping"객체를 실시간으로 출력하는 것은 불가능합니다. 파이프 라인에서 "meta"객체 만 출력 할 수 있습니다. 사용자는 항상 빈 화면을 보게됩니다.

메타 개체는 필요하지 않습니다. 위의 제안에서 언급했듯이 _each_ PingReply 또는 추적 홉에 대한 개체가 생성되고 출력됩니다. 모의 업, 아이디어를 설명하는 형식을 복제하는 단지 쉽게 최종 코드가 아닙니다. 테이블의 각 항목은 하나씩 출력됩니다. 전체 제안을 읽으십시오.

자세한 정보 스트림에 중요한 정보를 출력하는 cmdlet을 알지 못합니다. cmdlet 실행 프로세스를 이해할 수 있도록 항상이 스트림을 사용하여 추가 진단 정보를 표시합니다.

또한 정기적으로 정보 / 호스트에 "중요한"정보를 출력하고 다른 개체에 여러 수준 깊이 묻혀있는 경우를 제외하고는 출력하지 않는 _any_ cmdlet을 알지 못합니다.

단일 매개 변수 세트에 적합합니다. 이제 많은 매개 변수 세트가 있으며 각각을 명시 적으로 지정해야합니다.

그렇게하는 것이별로 유용하지 않다고 생각하지만, 내가 생각하기에 상당한 피해를 입히지는 않습니다. 나는 단순히 시간 낭비라고 생각합니다. 나는 많은 사람들이 기본 동작에 대한 스위치를 지정하는 데 많은 사용을 보게 될 것이라고 확신하지 않습니다.

메타 개체는 필요하지 않습니다.

_ 중요하게 필요합니다 ._
이 접근 방식은 cmdlet을 쓸모 없게 만듭니다. 네트워크에 문제가있는 경우 해당 cmdlet을 사용하여 진단을 실행 해보십시오. 너는 이것을 못해. 당신은 그것을 던지고 ping 및 traceroute 유틸리티를 사용합니다. 그러나 이제 콘솔과 예를 들어 스크립트가있는 모니터링 시스템에서 새 cmdlet을 사용하여 동일한 진단을 수행 할 수 있습니다. 정기적 인 네트워크 진단을하지 않으면 이해하기 어렵다는 것을 알고 있습니다. 이러한 기본 유틸리티, 특히 Unix 버전에서 얼마나 많은 매개 변수가 있는지 확인하십시오. 그들 모두는 진단에 중요합니다. 진단의 기술은 그들의 조합과 마법의 의미를 사용하는 것으로 구성됩니다. 이 모든 것을 새 cmdlet에 추가하려고했습니다.

그냥 시간 낭비라고 생각합니다

위치 매개 변수를 사용하면 도움이됩니다. :-)

PowerShell Committee에 대한 간략한 요약입니다.

현재 cmdlet은 설계되었습니다.

• 지원되는 모든 플랫폼에 대한 이식 가능한 cmdlet을 얻으려면 실제로 .Net Core에 여전히 몇 가지 문제가 있으므로 모든 기능이 Unix 계획 양식에서 작동하는 것은 아닙니다.
• ping, traceroute, pathping, Portqry.exe 등과 같은 인기있는 도구의 기능을 얻으려면
• 단순하고 심층적 인 네트워크 접근성 분석에 적합한 __scripts__에서 유용한 출력 객체를 얻으려면
• _header_ 및 _footer_로 유용한 콘솔 출력을 얻으려면. cmdlet은 일부 시나리오에서 기본 prototope 유틸리티보다 훨씬 더 유용한 정보를 표시합니다.
• 원격 테스트 "Test-Connection -Source ... -Destination ..."과 같은 향후 개선 사항을 허용합니다.

주요 문제는 대화 형 콘솔 출력 (대화 형 시나리오)과 파이프 라인의 개체 출력 (스크립트 시나리오)을 결합하는 방법입니다. 내 현재 제안은 매개 변수 (-Interactive) 또는 새 cmdlet (대화 형 시나리오의 경우 Show-Connectivity 및 스크립트 시나리오의 경우 Test-Connectivity)을 사용하여 분할하는 것입니다.
또한 cmdlet의 이름을 더 정확한 Test -__ Connectivity__로 변경하는 것이 좋습니다. 또한 이름 충돌없이 프록시 (WCM)를 통해 이전 Windows cmdlet을 무료로 사용할 수 있습니다.

@iSazonov 모든 데이터를 숨기는 메타 개체가 있어야하는 진단의 예를 제공 할 수 있습니까? 내 제안은 메타 개체의 정보를 각 PingReply 개체로 이동하는 것입니다. 이로 인해 cmdlet의 유용성이 어떻게 감소하는지는 알 수 없습니다.

생성 직후 개체를 출력하는 경우 바닥 글의 통계를 첫 번째 "ping"개체에 어떻게 넣습니까?

바닥 글 정보는 무엇입니까? 핑의 유일한 바닥 글 정보는 Ping complete.

현재 메타 개체에는 어디에서나 볼 수있는 통계가 없습니다. 정보 스트림에서 문자열 데이터로 렌더링되는 동일한 정보를 가진 모든 개체를 덜 사용 가능한 형식으로 포함합니다.

여기서 요점은 cmdlet (이 경우 Test-Connection)을 두 버전 (WinPS 및 Pwsh)에서 동일한 방식으로 유지하는 것입니다.이 경우 cmdlet에 스위치를 추가하여이 경우 출력이 잘못 될 것이라는 점을 언급했습니다. 이 cmdlet을 사용하는 모든 스크립트 / 모듈을 업데이트해야 함을 의미하기 전에 솔루션은 두 버전에서 동일한 방식으로 만듭니다.

@ NJ-Dude Windows cmdlet은 WMI를 기반으로하며 이전 버전과의 호환성으로 포팅 할 수 없습니다. 또한 5.1이 동결되었습니다. 앞으로 추가 할 사항이 없습니다.

@ NJ-Dude Windows cmdlet은 WMI를 기반으로하며 이전 버전과의 호환성으로 포팅 할 수 없습니다. 또한 5.1이 동결되었습니다. 앞으로 추가 할 사항이 없습니다.

저는 SYNTAX와 기능이 동일해야한다는 것을 이해하고 알고 있습니다. 즉, QUIET를 사용하면 출력이 표시되지 않으면 사용중인 PS의 종류에 관계없이 출력이 표시되지 않아야합니다.

나는 단지 SYNTAX와 기능이 동일해야한다고 말하는 것입니다.

불가능하다. Windows 호환성 모듈은 이전 기능을 얻는 단일 방법입니다.

cmdlet의 출력은 기본 출력과 분리 된 콘솔에 대한 원치 않는 표시를 수동으로 억제하지 않고도 저장 및 사용할 수 있어야합니다.

이러한 방식으로 작동하는 _ 다른 cmdlet은 없습니다 _. 가장 유용한 데이터는 정보 스트림의 문자열 형식입니다. 이런 식으로 행동 할 이유가 없습니다. 모든 데이터는 출력 스트림 period 에 있어야합니다. 추가 데이터는 필요에 따라 상세 또는 디버그 스트림에 있습니다. 이러한 방식으로 정보 스트림을 사용하는 것은 PowerShell 자체와 함께 제공되는 cmdlet의 경우 문자 그대로 전례없는 일입니다.

그리고 언급했듯이 바닥 글에 구체적으로 포함되어야하는 데이터가 언급하지 않았습니다. 처음부터 또는 각 응답이 처리 될 때 모두 사용할 수 있습니다.

위원회 토론을 위해 대기

Soooo 나는 잡초에서 문제가 발생하여 여기에서 스레드를 약간 잃어 버렸지 만 구현에 관계없이 기본적으로 취하는 것은 다음과 같습니다.

• 데이터는 라인 단위로 출력되어야합니다. Test-Connection s와 ping.exe et al 모두 현재의 경우라고 생각합니다.
• 데이터는 구조화 된 객체로 반환되어야합니다. 형식은이 사실을 무시해야합니다. (이것이 끔찍하지만, 내부적으로 PSObject라는 사실에도 불구하고 콘솔에 JSON 문자열을 내보내는 포맷터를 보았습니다. 제 요점은 간단하게 할 수 있다는 것입니다.) 포맷팅도 우리가하는 곳입니다. 변경 사항을 깨지 않고 원하는대로 변경할 수 있습니다. (또한 속성 이름과 일치하지 않는 열 머리글에 대해주의해야한다는 @ vexx32의 의견도 강력히 동의합니다. 가독성을 위해 필요한 경우도 있지만 이는 저를 미치게합니다.)
• -Quiet 는 Windows PowerShell과 마찬가지로 True / False를 부울로 제외하고 아무것도 내 보내지 않아야합니다.
• 기본 케이스 (최소 부울 -Quiet 케이스보다 더 많아야 함)보다 더 많은 정보를 내야하는 경우 -Verbose 합리적으로 들리지만 충분히 생각하지 않았습니다. (이것은 또한 내가 스레드를 잃는 곳이며 더 많은 사람들이 원하는 것을 말하기 어렵습니다).
• .NET Core, WMI 등으로 인해 Windows PowerShell과 동일한 속성을 가진 똑같은 개체 ( cimv2\Win32_PingStatus )를 모방하는 것은 불가능하지만 가능한 한 가깝게 만들어야합니다.
• 진행 상황에 대해 잘 모릅니다. 내 높은 수준의 견해는 진행이 느리기 때문에 (최적화에도 불구하고) 여전히 모든 사람을 미치게 만들지 만, 모든 사람이 어쨌든 $ProgressPreference 설정하고 있기 때문에 비대화 형에서는 그다지 중요하지 않다는 것입니다.

나에게 좋은 소리!

진행은 주로 명령 호출에서 처리 할 수 ​​없기 때문에 나를 짜증나게합니다. $ ProgressPreference를 설정해야합니다. 나는 그것이 공통된 매개 변수 였으면 좋겠다 .... 그러나 그것에 대해 또 다른 문제가있다. 그래서 여기서 그것에 대해 다루지 말자! :미소:

@ PowerShell / powershell-committee가 이것을 검토했습니다. Test-Connection 는 Windows PowerShell 5.1에서와 같이 가능한 한 가깝게 ( -Quiet ) 동작을 에뮬레이션해야한다는 데 동의했습니다. 이것은 PingStatus 출력 객체 ( win32_ )가 기본 형식의 속성과 사용 가능한 추가 항목을 갖는 각 응답에 대해 내 보내야 함을 의미합니다. 진행률을 사용해서는 안됩니다.

검토를 위해 제안 된 출력 형식과 함께 cmdlet 구문을 보여주는 짧은 RFC를 작성할 의향이 있습니까?

@ stevel-msft 나는 기뻐할 것입니다. :)

나는 그 소리를 좋아합니다.
감사

PR 3125가이 모든 것을 다루었지만 Test-Connection의 사용이 거부되었다는 점이 흥미 롭습니다. 그러나 이제 우리는 완전한 원을 만들었습니다. 3125를 되돌아 보는 것은 어떻습니까?

간단히 살펴보면 Windows 명령을 에뮬레이트하기 위해 기본적으로 Test-Connection을 Unix 플랫폼에서 다르게 구현 된 명령으로 대체 한 것처럼 보입니다. 내가 읽는 게 맞아?

나는 그것이 우리에게 가능한 최선의 선택이라고 생각하지 않습니다. 전체적으로 명령을 구현할 때 두 플랫폼 간의 일관성이 더 중요합니다. 우리가 활용할 수있는 흥미로운 아이디어가있을 수 있습니다.

RFC 작성이 끝나면 RFC 초안에 대한 링크를 삭제하고 자유롭게 의견을 말하고 조정하는 등의 작업을 할 것입니다. 이에 대한 더 많은 견해를 듣고 싶습니다. 🙂

편집 : https://github.com/PowerShell/PowerShell-RFC/pull/172

이 메시지를 표시하는 구체적인 사용 사례는 Linux에서 PowerShell Core를 사용하려는 욕구를 기반으로했지만 구현은 Windows와 Linux 모두에서 완전히 테스트되었습니다. 누락 된 명령 전체를 대체하기위한 것입니다.

언제 이것을 볼 수 있습니까? 6.2.2에서? 언제 그럴 가능성이 있습니까?
(이 스레드가 2018 년 4 월부터 지금까지 _-quiet_ 시끄러워지는 것을 보는 것은 재미있었습니다. 그렇게 생각할 필요가없는 브레이킹 체인지 인 것 같습니다)

이 코드를 꽤 쉽게 작성할 수 있습니다. RFC가 승인되기를 기다리고 있습니다. 그 일이 일어나는 즉시 나는 그것을 끝내고 이것에 대한 PR을 제출할 것입니다. :미소:

오, 상태가 승인되었다고 생각했습니다 (정확히 어떤 상태가 있는지 또는 전체 프로세스가 무엇인지 알지 못함). 하지만 업데이트 주셔서 감사합니다. 조용하게 만드는 데 12 개월이 넘게 걸린다는 사실이 여전히 아쉽습니다. :)

조용히하기 위해 12 개월 이상

더 많은 피드백을 기대했습니다

@ vexx32 코딩을 시작하고 현재 제안을 변경하는 피드백이 들어 오면 실험 플래그 뒤에 넣을 수 있습니다.

@ SteveL-MSFT 이미 대부분 작동하는 구현이 있습니다. 코드에 대해 좀 더 구체적으로 이야기 할 수 있도록 몇 가지 실험적 플래그가 포함 된 PR을 곧 제출할 예정입니다. 💖

지난 며칠 동안 원하는 동작에 대해 생각한 후에는 기본적으로 최소한의 매개 변수 (빠른 입력 및 사용자 친화적 인 디스플레이)로 대화 형 동작을 선호합니다. 이는 대화 형 세션에서 편리합니다. 추가 매개 변수를 사용하여 스크립트 스타일로 변환합니다 (이는 출력에서 ​​다른 유형을 의미 함).

@isazonov가 어떻게 작동 할 수 있다고 생각하는지 좀 더 자세히 설명해 주시겠습니까?

@ vexx32 구현 또는 UX 디자인에 대해 질문하십니까?

주로 UX가 그럴 것이라고 생각합니다. :)

인터랙티브 세션에서 최고의 UX는
1. 최소한의 타이핑
그 뜻은:
-ping이 기본값입니다.
-하나의 매개 변수로 다른 모드 (traceroute 등)로 전환
2. 사용자 친화적 인 출력
그 뜻은:
-ping.exe (tracert.exe 및 기타) 출력 _ 콘솔 호스트에서 _ 내가 데모 코드에서 시도한 것처럼 헤더, 바닥 글 및 정보 행이 잘 형식화되어 에뮬레이션합니다. 출력 유형에 대해 생각할 필요가 없습니다. 사용되지 않고 표시 만됩니다.
-스크립트 모드로 전환하기위한 매개 변수 추가-즉, 콘솔 호스트에서 사용자 친화적 인 텍스트의 출력을 억제하고 강력한 유형의 개체를 방출합니다. 이 출력을 형식화 할 필요가 없습니다. True / False를 반환하는 Quiet에 대해 논의했지만 다른 원시 강력한 유형 객체 (예 : -RawOutput)를 내보내려면 매개 변수가 필요합니다. 스크립트에서 추가 매개 변수를 사용하는 것은 허용되는 UX입니다.

고마워요, 당신이 지금 조금 더 나아지고있는 것을 이해하는 것 같아요.

그래도 이와 같은 듀얼 모드가 필요하다고 생각하지 않습니까? PowerShell의 다른 cmdlet에는 대화 형 매개 변수와 "스크립트 모드"매개 변수간에 이러한 분할이 없습니다.

ping / tracert의 정확한 출력을 원한다면 왜 이러한 유틸리티를 직접 사용하지 않겠습니까?

PowerShell은 기존 명령을 완전히 모방하기 위해 많은 노력을 기울인 적이 없습니다. Get-ChildItem이 아마도 가장 가까운 것이라고 생각하지만 거의 유일한 방법입니다.

당신이 말한 것처럼 ping / tracert 디스플레이를 철저히 에뮬레이트하고 싶다면, 대신 별도의 cmdlet 또는 함수 (예 : Show-Connection )로 사용하는 것이 좋습니다. PowerShell 내에서 선례 또는 필요.

그래도 이와 같은 듀얼 모드가 필요하다고 생각하지 않습니까? PowerShell의 다른 cmdlet에는 대화 형 매개 변수와 "스크립트 모드"매개 변수간에 이러한 분할이 없습니다.

포맷 시스템에 차이가 있습니다. 예를 들어 머리글 / 바닥 글 디렉터리를 요청하는 데 문제가 있습니다. 편리한 다른 시나리오가 있습니다.

ping / tracert의 정확한 출력을 원한다면 왜 이러한 유틸리티를 직접 사용하지 않겠습니까?

나는한다 :-). 이러한 기본 유틸리티는 저수준이지만 고정되어 있기 때문에 매우 강력합니다. 우리는 그들이하는 것보다 _smarter_ 일을 할 수 있습니다. 이것은 단지 ping을하기위한 것이 아니라이 cmdlet의 외관의 본질입니다. cmdlet의 주소와 이름이 어떻게 형성되고 어떻게 형성되는지 자세히 살펴보면 출력되면 네이티브 핑보다 훨씬 더 유용하다는 것을 알 수 있습니다. 속임수처럼 보이지만 정말 유용합니다.

물론 우리는 포맷팅 시스템에 차이가 있습니다. 하지만 대답은 _ 매번 _ 사용자 지정 솔루션을 구현하는 것이라고 생각하지 않습니다. 이는 더 많은 문제를 야기하고 전체적으로 더 효과적으로 포맷팅 시스템을 개선하거나 재 작성하는 것을 더욱 어렵게 만듭니다.

그래, 당신은 그것으로 몇 가지 훌륭한 작업을 수행했습니다! 대단히 감사합니다. 현재 출력 모드는 대화 형 사용에는 유용하지 않습니다. 출력 단계를 간단히 제거하고 Show-Connection 라고 부른 다음 RFC에서 설명하는대로 Test-Connection 자체에 대해보다 PowerShell 중심 솔루션에서 작성한 내용을 활용할 수 있습니다.

@ 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

그러나 변경 사항에 따라 모든 핑 응답은 단일 개체의 구성원입니다.

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 해당 개체 출력은 PS Core의 초기 구현에서 변경되지 않았습니다. 성공 출력에는 항상 단일 객체가 있습니다. 🙂

PR의 마지막 주석에서 언급했듯이 이는 검토를 단순화하는 데 도움이되는 RFC의 일부 구현 일뿐입니다. 곧 후속 PR을 제출하겠습니다. 이제 중복 된 커밋을 제거하기 위해 해당 분기를 리베이스하고 나머지를 제출하여 Windows PowerShell 구현과의 진정한 패리티에 훨씬 가까워지면됩니다. 여전히 다소 다를 수 있지만 (몇 주 전에 검토 한 RFC에서 볼 수 있듯이) 훨씬 더 다양해질 것입니다. 😊

@ SteveL-MSFT는이 모험의 다음 장을 위해 # 10697을 참조하십시오! 😊

: tada :이 문제는 # 10478에서 해결되었으며 이제 v7.0.0-preview.5 . : tada :

편리한 링크 :

• 릴리즈 노트

릴리스 7.0.0에서 Test-Connection -Quiet은 여전히
Test-Connection : 'scrubbed'컴퓨터에 대한 연결 테스트 실패 : 대상 이름을 확인할 수 없습니다.
대신에
그릇된

@chvol 가능한 한 자세한 내용으로 새로운 문제를 열 ​​수 있습니까?

감사! 🙂