Ini berfungsi dengan baik di 5.1 tetapi tidak di 6 jadi saya telah mengklasifikasikan ulang masalah sebagai bug.

Alasannya adalah bahwa kode saat ini memanggil WriteInformation (secara membabi buta?).

Lihat baris 751 dari TestConnectionCommand.cs , juga baris 775 dan baris 783.

Solusi sementara untuk menghentikan informasi agar tidak ditampilkan ke host adalah dengan menggunakan parameter umum InformationAction . Contoh:

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

Dari perspektif skrip , ini tidak akan menjadi masalah , karena informasi tekstual tidak pernah ditulis ke pipeline, dan tidak, keluaran tekstual bukan bagian dari data hasil, yang didefinisikan sebagai hal yang dikirim ke pipeline. Juga, Quiet switch didefinisikan untuk mengembalikan hasil yang lebih sederhana ( int atau bool , sebagai ganti objek record). Saya harus mengakui bahwa seseorang mungkin tidak mengharapkan InformationRecord dengan Quiet . Namun, mengetahui alasannya, saya katakan sebaiknya kita menyimpan InformationAction dan Quiet dipisahkan.

Di PowerShell 5.1, Test-Connection sepertinya tidak memanggil WriteInformation sama sekali. Omong-omong, nilai default untuk $InformationPreference di PowerShell 5.1 dan PowerShell Core 6.0.2 adalah SilentlyContinue . Penulis masalah mungkin memiliki nilai efektif yang berbeda ketika dia mereproduksi masalah tersebut. (Mungkin PS 6.1 Core mengubah nilai default untuk $InformationPreference ? Saya tidak yakin.)

Jika PS 6.1 Core memiliki $InformationPreference default ke SilentlyContinue , informasi tekstual tidak akan ada kecuali pengguna secara eksplisit memintanya.

Saya butuh lebih banyak umpan balik.
Masalahnya adalah bahwa dalam mode skrip dan mode interaktif, seharusnya berfungsi dengan cara yang berbeda. Dalam mode interaktif, pengguna mungkin lebih suka melihat kemajuan (bilah) seperti yang terjadi dengan perintah ping.exe. Ini juga berlaku untuk parameter lain.

@ mklement0 Jika Anda punya waktu, maka bantuan Anda akan berguna.

@Bayu_joo

Bagus ditemukan, tetapi -InformationAction Ignore yang diperlukan dalam kasus ini untuk mengatasi bug.

$InformationActionPreference masih default ke SilentlyContinue , dan itu seharusnya tidak berubah.

Bugnya adalah bahwa panggilan WriteInformation() Anda tautkan secara keliru menggunakan tag PSHOST , yang secara efektif _bypasses_ nilai $InformationActionPreference dan juga -InformationAction SilentlyContinue (tetapi, seperti yang dinyatakan , -InformationAction Ignore _is_ efektif dalam menekan keluaran).

Apa yang dikatakan WriteInformation() panggilan secara efektif adalah apa yang dilakukan Write-Host untuk _unconditionally_ menampilkan outputnya (berdasarkan desain).

@iSazonov : Saya belum benar-benar melihat perilaku cmdlet lain dengan bilah kemajuan, tetapi dengan -Quiet Saya _not_ mengharapkan bilah kemajuan, bahkan saat menelepon secara interaktif.

@ mklement0 Terima kasih atas balasannya dan koreksi atas PSHostTag . Menurut saya, InformationPreference ( InformationAction ) tidak menerima Ignore ? Ini benar di 5.1 dan 6.0.2. Mungkin di 6.1 itu berubah. (Apakah InformationActionPreference alias baru untuk InformationPreference ?)

Juga, komentar pertama saya salah, karena itu menetapkan InformationAction menjadi Continue . Solusi yang benar adalah dengan membuang aliran 6 (aliran informasi) dengan mengarahkannya ke $null , yaitu,

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

Periksa kebenarannya dengan yang berikut:

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

Seharusnya tidak menulis apa pun kepada tuan rumah.

@Bayu_joo

Menurut saya, InformationPreference (InformationAction) tidak menerima Abaikan?

Ya, variabel _preference_ tidak menerima Ignore , tetapi _common parameter_ menerima.

Artinya, Anda dapat menyembunyikan aliran informasi (nomor 6 ) _ untuk pemanggilan yang diberikan_, tetapi tidak _categorically_ untuk seluruh cakupan - dengan desain.

Oleh karena itu, dua pernyataan berikut ini setara:

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

Dengan kata lain: 6> $null dan -InformationAction Ignore adalah solusi yang efektif.

Apakah InformationActionPreference alias baru untuk InformationPreference ?

Tidak, namanya selalu $InformationPreference , mengikuti pola $VerbosePreference , $WarningPreference , dan $DebugPreference .

Dari apa yang bisa saya katakan itu hanya pasangan -ErrorAction / $ErrorActionPreference mana nama variabel preferensi mempertahankan bagian Action .

Selain itu mengenai larangan Ignore sebagai nilai dari tindakan _preferensi variabel_:

• Ada masalah desain mendasar dengan pembatasan ini, karena variabel preferensi lokal yang ditentukan secara otomatis digunakan untuk menyebarkan nilai parameter umum di dalam fungsi lanjutan - lihat # 1759

• Pembatasan tidak diberlakukan di _assignment time_, yang berarti Anda tidak akan melihat masalah sampai preferensi (mungkin secara implisit) diterapkan di lain waktu - lihat # 4348

  • Secara lebih umum, dalam lingkup apapun kecuali yang global, tidak ada validasi yang dilakukan sama sekali; bandingkan $ErrorActionPreference = 'bogus' dengan & { $ErrorActionPreference = 'bogus' } - lihat
    

    3483.

@ mklement0 Saya bertanya tentang alias karena Anda menyebutkannya sebagai InformationActionPreference .

Sepengetahuan saya, -XxxAction (dan -Verbose dan -Debug ) cukup menetapkan variabel preferensi yang sesuai di dalam cmdlet yang dipanggil. Seperti yang didokumentasikan dalam about_ topik bantuan, secara khusus kami memiliki yang berikut ini:

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.

Saya menafsirkan ini sebagai pengaturan variabel preferensi lokal, seperti yang dapat divalidasi dengan demonstrasi berikut:

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

Di 5.1 dan 6.0.2, InformationAction tidak menerima Ignore , seperti yang dapat ditunjukkan oleh cuplikan berikut:

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

menghasilkan

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

Saya ingin tahu apakah itu berubah di 6.1.

Ada hal menarik lainnya: $VerbosePreference dan $DebugPreference sebenarnya menerima rentang yang lebih luas daripada yang dapat diatur oleh parameter umum yang sesuai. Misalnya, dimungkinkan untuk menyetel $VerbosePreference menjadi Inquire dengan penetapan eksplisit, tetapi tidak mungkin dengan menggunakan sakelar -Verbose karena, bagaimanapun, ini adalah sakelar dan memetakan $True / $False menjadi Continue / SilentlyContinue .

Sejauh yang saya tahu, kecuali untuk dua sakelar tersebut, parameter umum yang terkait dengan preferensi dipetakan secara tepat ke variabel preferensi yang sesuai dalam lingkup lokal.

Putaran lain dari bermain-main menunjukkan kode berikut berfungsi:

Write-Information 'writing' -InformationAction Ignore

Tetapi itu akan merepotkan pengembang, karena kita harus menjaga Write-Information dengan cek $InformationAction -eq 'Ignore' , dan menghindari memanggilnya sejak awal, misalnya,

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

Tampaknya hal yang sama berlaku untuk penulis yang menulis cmdlet dengan C #.

@Tokopedia

Saya bertanya tentang alias karena Anda menyebutkannya sebagai InformationActionPreference.

Ups! Maaf - tidak menyadari kesalahan ketik saya sendiri.

cukup setel variabel preferensi yang sesuai di dalam cmdlet yang dipanggil.

Ya, dan hal lain yang Anda tunjukkan adalah subjek dari # 1759 yang disebutkan di atas.

Singkatnya: Cacat desain adalah bahwa pelarangan Ignore sebagai nilai variabel preferensi bentrok dengan penggunaan instance variabel preferensi lokal yang disetel secara otomatis untuk menyebarkan nilai parameter umum.

Lebih spesifik:

Di 5.1 dan 6.0.2, InformationAction tidak menerima Abaikan, seperti yang dapat ditunjukkan oleh cuplikan berikut:

Karena itu penting sehubungan dengan menyelesaikan masalah, izinkan saya menunjukkan bahwa -InformationAction _does_ menerima Ignore , dan hanya dikatakan cacat desain yang menyebabkan masalah _if dan ketika preferensi diterapkan_ dalam konteks dari _fungsi lanjutan_, yang dalam kasus Anda adalah Write-Information panggilan _inside_ fungsi.
Masalah ini berlanjut sejak PowerShell Core v6.1.0-preview.2.

_Compiled cmdlets_, sebaliknya, tidak memiliki masalah ini, itulah sebabnya Write-Host foo -InformationAction Ignore berfungsi sebagaimana mestinya, misalnya, seperti yang Anda temukan sejak itu.

Untuk meringkas, kami telah membahas dua masalah yang tidak terkait di sini:

• Cacat desain terkait dengan Ignore sebagai nilai variabel preferensi tindakan, yang sudah dilacak di # 1759.

• Topik asli terbitan ini, kesalahan Test-Connection cmdlet, yang salah menggunakan tag PSHOST dalam panggilannya ke .WriteInformation .

Solusi untuk yang terakhir adalah dengan hanya _omit_ tag, seperti yang ditunjukkan contoh berikut:

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

Jadi saya menemukan ini karena saya mengalami masalah yang sama di mana -Tenang tidak dihormati. Saya melihat kodenya dan itu agak sulit untuk diikuti dan sangat rumit untuk apa yang dilakukannya, tetapi saya tidak melihat di mana pun yang benar-benar mencari ini sebagai masalah menekan keluaran, saya juga tidak melihat dari mana ia beralih. mengeluarkan string ke boolean, yang harus dikeluarkan saat parameter -Quiet diteruskan.

Saya memang mengirimkan PR tahun lalu (# 2537) untuk menambahkan Test-Connection ke kode dan itu ditolak pada saat itu karena "@ PowerShell / PowerShell-committee tidak akan menerima PR ini karena akan menimbulkan masalah kompatibilitas di masa mendatang", jadi saya terkejut melihat masuknya cmdlet ini sekarang tetapi tidak dengan kode PR asli melainkan kode baru yang tidak menyediakan semua fungsi yang diharapkan.

Masalah terbesar yang saya temui adalah di skrip saya, saya melakukan pemeriksaan seperti ini, "jika (Test-Connection 8.8.8.8 -Quiet)" untuk bercabang ke logika saya, tetapi dengan parameter -Quiet tidak dihormati, cabang selalu mengembalikan True karena tidak ada False atau Null. Jadi ini membuat perintah masih benar-benar tidak dapat digunakan bagi saya, dan juga karena sudah disertakan dalam rilis baru PowerShell, yang membuat peningkatan sangat sensitif bagi saya. Harap perbaiki ini karena tampaknya sudah beberapa bulan sejak masalah pertama kali dilaporkan. Baik itu, atau pasang kembali PR asli, tidak masalah selama fungsinya dikembalikan.

Saya memang mengirimkan PR tahun lalu untuk menambahkan Test-Connection ke kode dan itu ditolak pada saat itu karena mereka tidak ingin menambahkan cmdlet lama, jadi saya terkejut melihat penyertaan cmdlet ini sekarang tetapi tidak dengan kodenya dari PR asli yang lengkap dan berfungsi persis seperti versi "lama".

Jika kita memiliki Test-Connection pada 5.1 dan 6.x, saya berharap mereka memiliki keluaran yang sama. Saya tahu penerapannya berbeda, tetapi pengguna seharusnya tidak peduli tentang itu. Tes-Koneksi saat ini di 6.1 berperilaku berbeda memberi kita keluaran yang berbeda dari 5.1. Selain itu, parameter -Quiet praktis tidak berguna.

Tampaknya masalah ini masih ada, sampai sekarang (PSVersion = 6.2.0) cmdlet terus menampilkan informasi "ping" bahkan jika QUIET ada (menambahkan "-InformationAction Ignore" melakukan trik tetapi itu berarti modul / skrip menggunakan cmdlet Test-Connection harus diperbarui, tidak keren)

Akan sangat menyenangkan jika kita bisa memperbaikinya untuk 7.0. Saya sangat senang untuk menyumbangkan kode, tetapi kami memerlukan spesifikasi implementasi untuk diikuti karena sangat sedikit kesepakatan tentang upaya sebelumnya untuk meningkatkan ini.

cc @ SteveL-MSFT @Sazonov

Saya kembali ke ini dari waktu ke waktu. Sekarang saya percaya bahwa kita dapat menyelesaikan ini dengan menggunakan pemisahan eksplisit skenario interaktif dan non-interaktif dengan -Intercative switch. Dengan parameter kita dapat mengimplementasikan keluaran konsol yang kaya dan ramah pengguna. Tampaknya tidak terlalu merepotkan bagi pengguna untuk mengetik parameter ini (seperti "-i"). Tanpa sakelar kami akan melakukan output yang diketik dengan kuat tanpa output konsol verba yang bagus untuk skenario skrip.

Mengingat bahwa tidak ada cmdlet lain yang menggunakan parameter seperti itu, menurut saya tidak masuk akal untuk memiliki dualitas seperti itu. Sebuah cmdlet harus melakukan tugasnya dan berperilaku secara konsisten; Perilaku interaktif tidak boleh dipisahkan dari perilaku yang lain.

Misalnya, lihat Get-ChildItem. Secara interaktif, ini sangat berguna berkat tampilan pemformat default. Tidak ada perubahan yang diperlukan untuk membuatnya berguna untuk tujuan otomatisasi; perintah yang sama yang bekerja secara interaktif juga berfungsi dalam skrip.

Itu kompleksitas yang tidak perlu, saya rasa.

Kita bisa melakukan keluaran interaktif secara default dan meningkatkan parameter Quiet untuk menekan keluaran dalam skrip.

Sekali lagi ... Saya tidak melihat kebutuhan untuk memiliki output yang berbeda secara interaktif vs dalam skrip.

Jika cmdlet hanya berperilaku seperti cmdlet lain dan mengeluarkan data yang tidak dapat digunakan alih-alih menjadi benar-benar unik dan mengeluarkan semua datanya dalam aliran teks yang sulit ditangkap atau diurai (ini adalah _PowerShell_, bukan Bash), sama sekali tidak perlu ada perubahan perilaku .

-Quiet adalah sakelar yang digunakan oleh cmdlet asli di Windows PowerShell untuk memberikan respons Benar / Salah murni, alih-alih mengeluarkan objek. Melanggar konvensi itu adalah ide yang buruk, menurut saya.

Cmdlet ini harus berperilaku konsisten dengan cmdlet yang ada. Tidak ada alasan untuk memilikinya sendiri menggunakan perilaku saat ini. Dalam iterasi saat ini, ia berperilaku lebih seperti yang diharapkan utilitas Unix untuk beroperasi, sangat berbeda dengan cara cmdlet PowerShell lainnya beroperasi.

Sekali lagi ... Saya tidak melihat kebutuhan untuk memiliki output yang berbeda secara interaktif vs dalam skrip.

Dapatkah Anda mendemonstrasikan hasil yang diinginkan dalam semua skenario yang didukung? Perhatikan bahwa informasi meta yang dihasilkan cmdlet sangat penting.

mengeluarkan semua datanya dalam aliran teks yang sulit ditangkap atau diurai

Cmdlet melakukan output objek yang diketik dengan kuat. (Masalahnya adalah tidak mungkin membangun objek ini dan menampilkannya secara bersamaan karena terdapat informasi "meta".)

-Quiet adalah sakelar yang digunakan oleh cmdlet asli di Windows PowerShell untuk memberikan respons Benar / Salah murni, alih-alih mengeluarkan objek. Melanggar konvensi itu adalah ide yang buruk, menurut saya.

Cmdlet Windows PowerShell hanya mendukung ping yang konsep koneksinya tidak ada. Ini awalnya desain kontroversial. Nama yang tepat untuk mereka adalah Test-Ping ot Test-ICMP .
Cmdlet saat ini mendukung "koneksi" ip. Meskipun saya lebih suka sesuatu seperti "Uji-Konektivitas".

Dalam iterasi saat ini, ia berperilaku lebih seperti yang diharapkan utilitas Unix untuk beroperasi, sangat berbeda dengan cara cmdlet PowerShell lainnya beroperasi.

Tidak, cmdlet melakukan output objek yang diketik dengan kuat. Dan keluaran konsol dibuat agar terlihat seperti utilitas. Tetapi pada saat yang sama, Anda mungkin melihat bahwa sebenarnya itu lebih kaya dan lebih berguna.
Masalahnya adalah bahwa keluaran ini tidak dapat diperoleh dengan menggunakan kapabilitas dari subsistem pemformatan dan perlu untuk membuat keluaran langsung ke konsol. (Perhatikan bahwa ini tidak tercampur dengan objek keluaran di aliran keluaran)

Output dapat diperoleh dengan sistem pemformatan, jika kita menyusun objek data dengan cara yang lebih kuat. Saya sudah mengirimkan PR dengan prototipe. Sebuah cmdlet yang menampilkan data dalam bentuk yang tidak benar-benar mencerminkan data objek yang mendasarinya (misalnya, dengan menampilkan data dari subproperti alih-alih menyusun kelas objek dengan benar) umumnya menyesatkan dan menurut saya harus dihindari sedapat mungkin.

Saya akan memeriksa ini lebih lanjut dan mengumpulkan contoh yang lebih lengkap tentang apa yang saya anggap sebagai keluaran yang diinginkan. Uji-Sambungan di Windows PowerShell mungkin merupakan desain yang kontroversial, tetapi saya pikir itu adalah langkah ke arah yang benar, jika sangat tidak lengkap.

@iSazonov Saya tidak setuju dengan Anda setelah membaca pertama TAPI setelah pengujian, saya memahami sudut pandang Anda

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

Nilai $ a dan $ b adalah apa yang saya harapkan TETAPI saya tidak ingin output ekstra.

Select-String juga memiliki Parameter Tenang dan tidak ada hubungannya dengan perilaku "interaktif"

Saya setuju bahwa perintah ini membutuhkan parameter tambahan untuk mengubah perilaku (Diam atau tidak).

Saya lebih suka parameter 'Interaktif' bukan secara default tetapi mungkin parameter saklar "NoInteractive" adalah penyesuaian yang lebih baik untuk membiarkan prioritas pada penggunaan interaktif.

Baiklah, inilah yang saya anggap sebagai implementasi yang agak lebih berguna.

Poin Umum

1. Semua keluaran informasi / host saat ini diturunkan ke aliran -Verbose . Saat ini yang tidak digunakan _at all_, dan ini adalah kasus penggunaan yang sempurna untuk itu.
2. Tidak ada bilah kemajuan kecuali ditentukan dengan tombol -ShowProgress .
3. Hapus tombol -Ping (ini adalah perilaku default).

Keluaran Utama

Test-Connection www.google.com

• Informasi dari properti Replies dari objek output harus disertakan dalam objek output utama, dan mode output utama harus berupa objek _multiple_, masing-masing mewakili satu percobaan ping / objek balasan.
• Buffer _data_ umumnya tidak relevan, karena tidak dapat ditentukan, dan hanya properti BufferSize harus ditampilkan. Replies.Buffer properti harus tetap private .
• Replies.Options properti harus disembunyikan dari format default.
• Hasil keluaran berupa tabel, dikelompokkan berdasarkan alamat Tujuan (dalam hal beberapa tujuan ditentukan).

Keluarkan mockup visual

Perintah yang digunakan:

$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

Hasil keluaran:

   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

• Setiap lompatan harus dikeluarkan sebagai objek terpisah, masing-masing berisi objek PingReply sebagai properti yang dapat diakses dengan cara disembunyikan dari pemformatan.
• Objek utama TraceRouteResult harus berisi ETS atau properti kelas yang menghitung data ringkasan dari empat PingReplies mereka.
• Catatan: Jenis objek yang kami gunakan saat ini disadap , dan semua objek PingReply melaporkan TtlExpired sebagai statusnya. Rekomendasikan untuk menyelidiki kemajuan perbaikan untuk .NET Core 3, atau merancang solusi kustom untuk dukungan TraceRoute untuk menyelesaikan masalah.
• Output sebagai tabel, dikelompokkan menurut DestinationHost (Mengapa nama properti ini berbeda dengan tipe objek lain yang digunakan untuk ping standar?)

Keluarkan mockup visual

Perintah yang digunakan:

$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

Hasil keluaran:

   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

Saya sangat yakin bahwa jika kami menyajikan data kepada pengguna, data itu harus dapat diakses dengan cara terprogram, dengan struktur permukaan yang mirip dengan apa yang ditampilkan di layar. Mengganti nama properti atau mengubur data satu atau dua tingkat jauh di dalam properti objek keluaran hanya mengundang kebingungan, laporan bug, frustrasi, dan penurunan signifikan dalam kegunaan keseluruhan.

Oh, @ vexx32 Saya melihat Anda tidak pernah mendiagnosis jaringan. Proposal Anda diimplementasikan oleh saya pada langkah pertama dan kemudian ditolak karena tidak cocok untuk digunakan dalam sesi interaktif. Misalnya, kita dapat melihat layar kosong untuk waktu yang sangat lama setelah menjalankan perintah Test-Connection www.google.com -TraceRoute . Jadi implementasi diubah untuk menampilkan output (string atau progress bar) untuk setiap respons.

Semua keluaran informasi / host saat ini diturunkan ke aliran -Verbose. Saat ini itu tidak digunakan sama sekali, dan ini adalah kasus penggunaan yang sempurna untuk itu.

Saran saya di atas adalah untuk memperkenalkan Interactive switch untuk membagi interaktif dan skrip skenario. Anda menyarankan untuk melakukan hal yang sama dengan tombol Verbose yang merupakan praktik yang lebih tidak wajar.

Tidak ada bilah kemajuan kecuali ditentukan dengan sakelar -ShowProgress.

Output string dan progress bar dalam implementasi saat ini sebagai dua alternatif. Kami hanya membutuhkan satu. Bilah kemajuan digunakan dalam cmdlet Windows PowerShell. Preferensi saya adalah keluaran string dalam sesi interaktif. Jauh lebih nyaman.
Dan kami tidak pernah menekan bilah kemajuan dengan sakelar. Kami memiliki $ ProgressPreference untuk skenario skrip. Beberapa cmdlet menunjukkan bilah kemajuan hanya untuk operasi lama dengan pengatur waktu.

Hapus sakelar -Ping (ini adalah perilaku default).

Praktik terbaiknya adalah menggunakan parameter eksplisit dalam skrip. Itu membuat kode lebih mudah dibaca. Itu tidak diperlukan di cmdlet Windows PowerShell di mana hanya ping yang diterapkan. Cmdlet baru mengimplementasikan lebih banyak fungsi dan kami membutuhkan parameter eksplisit baru untuk setiap fungsi.

Proposal Anda diimplementasikan oleh saya pada langkah pertama dan kemudian ditolak karena tidak cocok untuk digunakan dalam sesi interaktif. Misalnya, kita dapat melihat layar kosong untuk waktu yang sangat lama setelah menjalankan perintah Test-Connection www.google.com -TraceRoute. Jadi implementasi diubah untuk menampilkan output (string atau progress bar) untuk setiap respons.

Tampilan kemajuan tidak diperlukan dengan format objek terpisah, karena kita dapat dengan mudah melihat kemajuan saat setiap objek dikirimkan ke keluaran. Satu-satunya alasan yang diperlukan di sini adalah karena kami tidak mengeluarkan data ke pipeline seperti yang diambil seperti yang dilakukan cmdlet PowerShell lainnya. Jika kita menampilkan setiap PingReply atau trace hop untuk -TraceRoute we _have_ tampilan kemajuan dibangun ke dalam tampilan keluaran.

Saran saya di atas adalah untuk memperkenalkan tombol Interaktif untuk memisahkan skenario interaktif dan skrip. Anda menyarankan untuk melakukan hal yang sama dengan tombol Verbose yang merupakan praktik yang lebih tidak wajar.

-Verbose adalah parameter umum dan dengan demikian merupakan pilihan yang jauh lebih alami untuk cmdlet daripada saklar yang benar-benar baru. Kita tidak perlu menemukan kembali kemudi di sini.

Praktik terbaiknya adalah menggunakan parameter eksplisit dalam skrip. Itu membuat kode lebih mudah dibaca. Itu tidak diperlukan di cmdlet Windows PowerShell di mana hanya ping yang diterapkan. Cmdlet baru mengimplementasikan lebih banyak fungsi dan kami membutuhkan parameter eksplisit baru untuk setiap fungsi.

Saya tidak di sini atau di sana dalam hal ini, tetapi biasanya perilaku default cmdlet tidak memiliki sakelar. Misalnya, kita tidak memiliki tombol -Loud sebagai kebalikan dari -Quiet .

Tampilan kemajuan tidak diperlukan dengan format objek terpisah, karena kita dapat dengan mudah melihat kemajuan saat setiap objek dikirimkan ke keluaran.

Dengan proposal Anda di atas, kami mengumpulkan objek "ping" dalam objek "meta" dan tidak mungkin mengeluarkan objek "ping" secara real time - kami hanya dapat mengeluarkan objek "meta" dalam pipeline - pengguna akan melihat tampilan kosong sepanjang waktu.

-Verbose adalah parameter umum dan dengan demikian merupakan pilihan yang jauh lebih alami untuk cmdlet daripada sakelar yang sama sekali baru.

Saya tidak mengetahui ada cmdlet yang mengeluarkan informasi penting ke aliran verbose. Kami selalu menggunakan aliran ini untuk menampilkan informasi diagnostik tambahan sehingga kami memahami proses menjalankan cmdlet.

biasanya perilaku default cmdlet tidak memiliki sakelar.

Itu tepat untuk set parameter tunggal. Sekarang kita memiliki banyak set parameter dan kita perlu menetapkan masing-masing secara eksplisit.

Dengan proposal Anda di atas, kami mengumpulkan objek "ping" dalam objek "meta" dan tidak mungkin mengeluarkan objek "ping" secara real time - kami hanya dapat mengeluarkan objek "meta" dalam pipeline - pengguna akan melihat tampilan kosong sepanjang waktu.

Objek meta tidak diperlukan. Seperti disebutkan dalam proposal di atas, objek akan dibuat dan dikeluarkan untuk _each_ PingReply atau trace hop. Maket bukanlah kode akhir, hanya format yang mudah diduplikasi untuk menggambarkan gagasan. Setiap entri dalam tabel akan menjadi keluaran satu per satu. Silakan baca proposal lengkapnya.

Saya tidak mengetahui ada cmdlet yang mengeluarkan informasi penting ke aliran verbose. Kami selalu menggunakan aliran ini untuk menampilkan informasi diagnostik tambahan sehingga kami memahami proses menjalankan cmdlet.

Saya juga tidak mengetahui _any_ cmdlet yang secara rutin mengeluarkan informasi "signifikan" ke informasi / host dan bukan ke keluaran kecuali terkubur beberapa level jauh di dalam objek lain.

Itu tepat untuk set parameter tunggal. Sekarang kita memiliki banyak set parameter dan kita perlu menetapkan masing-masing secara eksplisit.

Menurut saya tidak banyak gunanya melakukan hal itu, tetapi menurut saya itu tidak menimbulkan banyak kerugian. Saya hanya berpikir itu hanya membuang-buang waktu; Saya tidak yakin banyak orang akan melihat banyak kegunaan dalam menentukan sakelar untuk perilaku default.

Objek meta tidak diperlukan.

_Ini sangat penting._
Pendekatan ini membuat cmdlet menjadi hal yang tidak berguna. Jika Anda memiliki jaringan di mana ada masalah, coba jalankan diagnostik menggunakan cmdlet itu. Anda tidak bisa melakukan ini. Anda akan membuangnya dan mengambil utilitas ping dan traceroute. Tapi sekarang Anda dapat melakukan diagnostik yang sama dengan cmdlet baru di konsol dan, misalnya, di sistem pemantauan dengan skrip. Saya memahami bahwa sulit untuk dipahami jika Anda tidak melakukan diagnostik jaringan secara teratur. Lihat berapa banyak parameter yang dimiliki utilitas asli ini, terutama dalam versi Unix. Semuanya penting untuk diagnosis. Seni diagnosis terdiri dari penggunaan kombinasi dan makna magisnya. Saya mencoba menambahkan semua ini ke cmdlet baru.

Saya hanya berpikir itu hanya membuang-buang waktu

Menggunakan parameter posisi membantu Anda :-)

Ringkasan singkat untuk Komite PowerShell.

Cmdlet saat ini dirancang

• untuk mendapatkan cmdlet portabel untuk semua platform yang didukung. Sungguh, kami masih memiliki beberapa masalah di .Net Core jadi tidak semua fitur berfungsi pada planform Unix
• untuk mendapatkan fitur alat populer seperti ping, traceroute, pathping, Portqry.exe, dll
• untuk mendapatkan objek keluaran yang berguna dalam __scripts__ yang cocok untuk analisis aksesibilitas jaringan yang sederhana dan mendalam
• untuk mendapatkan keluaran konsol yang berguna dengan _header_ dan _footer_. Perhatikan bahwa cmdlet menampilkan informasi yang lebih berguna dalam beberapa skenario daripada utilitas prototop asli.
• untuk memungkinkan hal-hal yang tidak diinginkan di masa mendatang seperti pengujian jarak jauh "Test-Connection -ource ... -Destination ..."

Masalah utamanya adalah bagaimana menggabungkan output konsol interaktif (skenario interaktif) dan output objek dalam pipa (skenario skrip). Saran saya saat ini adalah membuat pemisahan baik dengan parameter (-Interactive) atau dengan cmdlet baru (Show-Connectivity untuk skenario interaktif dan Test-Connectivity untuk skenario skrip).
Saya juga menyarankan untuk mengubah nama cmdlet menjadi Test -__ Connectivity__ yang lebih akurat. Ini juga akan memungkinkan penggunaan cmdlet Windows lama secara gratis melalui proxying (WCM) tanpa konflik nama.

@iSazonov dapatkah Anda memberikan contoh diagnostik yang mengharuskan ada objek meta yang menyembunyikan semua data? Usulan saya adalah untuk memindahkan informasi dari objek meta ke setiap objek PingReply; Saya tidak melihat bagaimana hal itu akan menurunkan utilitas cmdlet.

Bagaimana Anda menempatkan statistik dari footer ke objek "ping" pertama jika Anda mengeluarkan objek segera setelah pembuatan?

Informasi footer apa? Satu-satunya informasi footer dari ping adalah Ping complete.

Tidak ada statistik dalam objek meta saat ini yang dapat saya lihat di mana pun; mereka hanya berisi semua objek dengan informasi yang sama yang dirender sebagai data string pada aliran informasi, hanya dalam format yang kurang dapat digunakan.

Intinya di sini adalah untuk menjaga cmdlet (dalam hal ini Test-Connection) dengan cara yang sama pada kedua versi (WinPS dan Pwsh) menambahkan sakelar ke cmdlet ke dalam hal ini untuk 'menonaktifkan' output itu akan salah karena seperti yang saya nyatakan sebelum itu berarti setiap skrip / modul yang menggunakan cmdlet ini harus diperbarui, solusinya adalah membuatnya dengan cara yang sama pada kedua versi

@ NJ-Dude cmdlet Windows didasarkan pada WMI dan tidak mungkin untuk mem-port-nya dengan kompatibilitas ke belakang. 5.1 juga dibekukan - tidak ada penambahan di masa mendatang.

@ NJ-Dude cmdlet Windows didasarkan pada WMI dan tidak mungkin untuk mem-port-nya dengan kompatibilitas ke belakang. 5.1 juga dibekukan - tidak ada penambahan di masa mendatang.

Saya mengerti dan tahu itu, saya hanya mengatakan SYNTAX dan fungsionalitasnya harus sama, artinya, jika menggunakan QUIET tidak menampilkan output apa pun maka seharusnya tidak menampilkan output apa pun terlepas dari rasa PS yang digunakan.

Saya hanya mengatakan SYNTAX dan fungsinya harus sama

Itu tidak mungkin. Modul Kompatibilitas Windows adalah satu cara untuk mendapatkan fungsionalitas lama.

Keluaran cmdlet harus dapat disimpan dan digunakan tanpa harus juga secara manual menyembunyikan tampilan yang tidak diinginkan ke konsol yang entah bagaimana terpisah dari keluaran utama.

_Tidak ada cmdlet_ lain yang berperilaku seperti ini, di mana data yang paling berguna adalah dalam bentuk string di aliran informasi. Tidak ada alasan untuk berperilaku seperti ini. Semua data harus ada di arus keluaran, titik . Data tambahan ada di aliran verbose atau debug sesuai kebutuhan. Penggunaan aliran informasi dengan cara ini benar-benar belum pernah terjadi sebelumnya untuk cmdlet yang dikirimkan dengan PowerShell itu sendiri.

Dan seperti yang disebutkan, tidak ada data di footer yang Anda sebutkan yang perlu secara khusus di footer; semuanya tersedia dari awal atau saat setiap respons diproses.

Mengantri ini untuk diskusi Komite

Soooo saya kehilangan jejak sedikit di sini, mengalami masalah di gulma, tetapi dasar saya tanpa memperhatikan penerapan adalah ini:

• Data harus keluaran baris demi baris. Saya pikir itu kasus saat ini dengan Test-Connection s dan ping.exe et al
• Data harus dikembalikan sebagai objek terstruktur. Pemformatannya harus agnostik dari fakta ini. (Betapapun mengerikannya ini, saya telah melihat pemformat yang memancarkan string JSON ke konsol meskipun faktanya itu adalah PSObject di bawah tenda. Maksud saya hanyalah bahwa itu bisa dilakukan.) Pemformatan juga merupakan tempat di mana kita diperbolehkan untuk mengubah apapun yang kita inginkan tanpa merusak perubahan. (Juga sangat setuju dengan @ vexx32 bahwa kita harus berhati-hati tentang tajuk kolom yang tidak cocok dengan nama properti. Terkadang diperlukan untuk keterbacaan, tetapi juga membuat saya gila.)
• -Quiet seharusnya tidak mengeluarkan apa pun kecuali True / False sebagai Boolean, seperti Windows PowerShell.
• Jika ada lebih banyak informasi yang perlu kita keluarkan daripada kasus default (yang seharusnya lebih dari boolean minimal -Quiet case), -Verbose terdengar masuk akal, tetapi saya belum cukup memikirkannya. (Di sinilah saya kehilangan utas, sulit untuk mengatakan apa yang diinginkan lebih banyak orang di atas).
• Meniru objek yang sama persis ( cimv2\Win32_PingStatus ) dengan semua properti yang sama seperti Windows PowerShell tidak mungkin (karena .NET Core, WMI, dll.), Tetapi kita harus mencoba membuatnya sedekat mungkin.
• Saya tidak tahu tentang kemajuan. Pengambilan tingkat tinggi saya adalah bahwa kemajuan masih membuat semua orang gila karena lambat (terlepas dari pengoptimalan kami), tetapi juga itu tidak terlalu penting dalam non-interaktif karena semua orang menetapkan $ProgressPreference pula.

Terdengar bagus untukku!

Kemajuan terutama mengganggu saya karena tidak dapat ditangani dalam pemanggilan perintah; Anda harus menyetel $ ProgressPreference. Saya benar-benar berharap itu adalah parameter umum .... Tetapi saya memiliki masalah lain yang mengeluhkannya, jadi jangan membahasnya di sini! :tersenyum:

@ PowerShell / powershell-committee telah mengulas ini. Kami setuju bahwa Test-Connection harus meniru perilaku seperti di Windows PowerShell 5.1 sedekat mungkin (termasuk -Quiet ). Ini berarti bahwa objek output PingStatus (menghapus win32_ ) harus dikeluarkan untuk setiap balasan yang memiliki properti dalam format default dan properti tambahan yang tersedia. Kemajuan tidak boleh digunakan.

Apakah seseorang akan bersedia untuk membuat RFC pendek yang menunjukkan sintaks cmdlet bersama dengan format keluaran yang diusulkan untuk ditinjau?

@ stevel-msft Saya akan dengan senang hati. :)

Saya suka suara itu.
Terima kasih

Agak menarik bahwa PR 3125 mencakup semua ini tetapi penggunaan Test-Connection ditolak, tetapi sekarang kita telah mencapai lingkaran penuh. Bagaimana dengan melihat kembali ke 3125?

Melihatnya secara singkat, sepertinya itu pada dasarnya menggantikan Test-Connection dengan perintah yang diimplementasikan secara berbeda pada platform Unix untuk mencoba meniru perintah Windows? Apakah saya membacanya dengan benar?

Saya rasa itu bukan pilihan terbaik yang tersedia bagi kita; konsistensi di kedua platform dalam implementasi perintah secara keseluruhan lebih berharga. Mungkin ada beberapa ide menarik yang bisa kita manfaatkan, saya yakin!

Saya akan meletakkan tautan ke draf RFC setelah saya selesai menulisnya & merasa bebas untuk berkomentar, menyesuaikan, dll ... Saya ingin mendengar lebih banyak sudut pandang tentang ini. 🙂

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

Kasus penggunaan khusus saya untuk meminta ini didasarkan pada keinginan untuk menggunakan PowerShell Core di Linux, tetapi implementasinya telah diuji sepenuhnya di Windows dan Linux. Itu dimaksudkan untuk menggantikan perintah yang hilang secara keseluruhan.

Kapan kita akan melihat ini? Di 6.2.2? Kapan kemungkinan itu akan mendarat?
(lucu melihat utas ini mengamuk dari April 2018 hingga sekarang karena _-quiet_ berisik. Sepertinya perubahan yang tidak perlu dipikirkan lagi)

Saya bisa mendapatkan kode ini ditulis dengan cukup mudah, saya pikir, saya hanya menunggu RFC diterima. Segera setelah itu terjadi, saya akan menyelesaikannya dan mengirimkan PR untuk ini. :tersenyum:

Oh saya pikir statusnya adalah disetujui (tidak tahu persis apa yang ada atau apa proses lengkapnya). Tapi terima kasih atas pembaruannya. Sayang sekali butuh lebih dari 12 bulan untuk membuatnya tenang :)

lebih dari 12 bulan untuk membuatnya tenang

Saya mengharapkan lebih banyak tanggapan

@ vexx32 Anda dapat mulai membuat kode ini dan meletakkannya di belakang bendera Eksperimental jika ada umpan balik yang mengubah proposal saat ini

@ SteveL-MSFT Saya sudah memiliki implementasi yang sebagian besar berfungsi. Saya akan segera mengirimkan PR dengan beberapa bendera Eksperimental sehingga kita dapat membicarakan kode secara lebih konkret. 💖

Setelah memikirkan di hari-hari terakhir tentang perilaku yang diinginkan, saya lebih memilih untuk memiliki perilaku interaktif dengan parameter minimum secara default (pengetikan cepat dan tampilan yang ramah pengguna), yang akan nyaman dalam sesi interaktif. Dan mengonversi ke gaya skrip dengan parameter tambahan (ini menyiratkan jenis keluaran yang berbeda).

Bisakah Anda menjelaskan lebih lanjut tentang bagaimana menurut Anda hal itu dapat berhasil pada @isazonov?

@ vexx32 Apakah Anda bertanya tentang implementasi atau desain UX?

Terutama menurut Anda UX akan seperti itu, menurut saya. :)

Dalam sesi interaktif, UX terbaik adalah
1. mengetik minimal
Itu berarti:
- ping adalah default
- beralih ke mode lain (traceroute dan lain-lain) dengan satu parameter
2. keluaran yang ramah pengguna
Itu berarti:
- meniru ping.exe (tracert.exe dan lainnya) keluaran _on konsol host_ seperti yang saya coba di kode demo - dengan header, footer, dan baris informatif yang diformat dengan baik. Tidak perlu memikirkan jenis keluaran - mereka tidak digunakan, hanya ditampilkan.
- tambahkan parameter untuk beralih ke mode skrip - yaitu untuk menekan keluaran teks yang mudah digunakan pada host konsol dan memancarkan objek yang diketik dengan kuat. Tidak perlu memformat keluaran ini. Kami membahas Quiet yang mengembalikan True / False tetapi kami membutuhkan parameter untuk memancarkan objek tipe kuat mentah lainnya (seperti -RawOutput). UX dapat diterima untuk menggunakan parameter tambahan dalam skrip.

Terima kasih, saya rasa saya mengerti apa yang Anda dapatkan dengan sedikit lebih baik sekarang.

Saya tidak benar-benar melihat perlunya mode ganda seperti ini? Tidak ada cmdlet lain di PowerShell yang memiliki pemisahan antara parameter interaktif dan "mode skrip".

Jika Anda menginginkan keluaran ping / tracert yang tepat, mengapa Anda tidak langsung menggunakan utilitas tersebut?

PowerShell tidak pernah melakukan upaya signifikan untuk sepenuhnya meniru perintah yang ada; Saya pikir Get-ChildItem mungkin yang paling dekat, tetapi hampir satu-satunya yang melakukannya.

Jika kita ingin benar-benar meniru tampilan ping / tracert seperti yang Anda katakan, saya sarankan agar kita memilikinya sebagai cmdlet atau fungsi terpisah, misalnya, Show-Connection , daripada kekacauan Show-Command dengan parameter tambahan yang tidak ada. preseden atau kebutuhan dalam PowerShell.

Saya tidak benar-benar melihat perlunya mode ganda seperti ini? Tidak ada cmdlet lain di PowerShell yang memiliki pemisahan antara parameter interaktif dan "mode skrip".

Kami memiliki celah dalam sistem pemformatan keluar. Misalnya, kami memiliki masalah dengan permintaan untuk memiliki direktori header / footer. Ada skenario lain yang lebih nyaman.

Jika Anda menginginkan keluaran ping / tracert yang tepat, mengapa Anda tidak langsung menggunakan utilitas tersebut?

Saya lakukan :-). Utilitas asli ini sangat kuat karena levelnya rendah tetapi dibekukan. Kami dapat melakukan _smarter_ daripada yang mereka lakukan - ini adalah inti dari penampilan cmdlet ini (dan bukan hanya untuk membuat ping) - jika Anda melihat lebih dalam bagaimana alamat dan nama di cmdlet sekarang terbentuk dan bagaimana mereka adalah keluaran, Anda akan melihat bahwa ada jauh lebih berguna daripada di ping asli. Ini terlihat seperti trik tetapi sangat berguna.

Tentu saja kami memiliki celah dalam sistem pemformatan. Namun menurut saya jawabannya adalah dengan menerapkan solusi kustom _setiap kali_. Itu hanya menciptakan lebih banyak masalah dan membuatnya semakin sulit untuk meningkatkan atau menulis ulang sistem pemformatan agar lebih efektif secara keseluruhan.

Ya, Anda telah melakukan beberapa pekerjaan hebat dengannya! Saya sangat menghargai itu. Mode keluaran saat ini tidak berguna untuk penggunaan interaktif apa pun _but_. Kami cukup menghapus langkah keluaran dan menyebutnya Show-Connection dan kemudian memanfaatkan apa yang telah Anda tulis dalam solusi yang lebih berfokus pada PowerShell untuk Test-Connection itu sendiri seperti yang saya uraikan di RFC.

@ vexx32 Saya baru saja mencoba PR Anda dan itu meningkatkannya sedikit, tetapi saya perhatikan bahwa di Windows PowerShell, itu memancarkan PingReply secara individual ke pipa sehingga Anda mendapatkan sesuatu yang terlihat seperti:

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

Namun, dengan perubahan Anda, semua balasan ping adalah anggota dari satu objek:

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…

Apakah kami tidak dapat mengembalikan perilaku Windows PowerShell?

@ SteveL-MSFT Output objek tidak berubah dari implementasi awal di PS Core; keluaran sukses selalu memiliki satu objek. 🙂

Seperti yang disebutkan dalam komentar penutup PR, itu hanya implementasi sebagian dari RFC untuk membantu menyederhanakan tinjauan. Saya akan segera mengirimkan PR tindak lanjut. Hanya perlu me-rebase cabang itu untuk menghapus komit yang sekarang duplikat dan mengirimkan sisanya untuk mendekati paritas sebenarnya dengan implementasi Windows PowerShell. Ini masih akan sedikit berbeda (seperti yang dapat dilihat dari RFC yang kami ulas beberapa minggu yang lalu) tetapi mudah-mudahan akan jauh lebih fleksibel. 😊

@ SteveL-MSFT lihat # 10697 untuk bab selanjutnya dalam petualangan ini! 😊

: tada: Masalah v7.0.0-preview.5 .: tada:

Tautan yang berguna:

• Catatan Rilis

Dalam rilis 7.0.0 Test-Connection -Quiet masih memberikan
Test-Connection: Pengujian koneksi ke komputer yang 'digosok' gagal: Tidak dapat menyelesaikan nama target.
dari pada
Salah

@chvol Bisakah Anda membuka edisi baru untuk itu sedetail mungkin?

Terima kasih! 🙂