Powershell: Bisakah kita menggunakan | di baris berikutnya sebagai karakter lanjutan?

Dalam skrip - ya, tetapi itu akan merusak kemampuan untuk menggunakan klik kanan sekolah lama atau Alt+e,p tempel di konsol karena setelah masuk, Anda akan memiliki baris perintah yang lengkap.

Diskusi terkait #2819

Saya melihat UX buruk untuk sesi interaktif: setelah parser NewLine akan menunggu NewLine atau melewatkan spasi hingga | atau NewLine - ini akan membingungkan pengguna .

Untuk skrip ini adalah permintaan untuk menghapus karakter lanjutan ` (backtick) tepat waktu karena kami selalu dapat mengetik:

$result = Get-Process |
     Where WS -gt 500mb |
     Format-Table VM, WS, CPU, ID, ProcessName

Pengurai sudah melakukan ini di tempat lain.

if( 1 -eq (get-random 2)) {
    "True"
}
else {
    "False"
}

@lzybkr jelas memiliki parser yang dapat memahami itu tidak berarti orang _harus_ menulis banyak baris seperti itu -- banyak orang telah mengadopsi gaya stroustrup seperti di atas, atau bahkan "mengikat pada baris mereka sendiri" dan hal-hal gaya lain yang merusak tempel (terutama karena PSReadLine mengacaukan klik kanan dan membuat Ctrl+V berfungsi). Itu seharusnya tidak membuat perbedaan.

@iSazonov secara interaktif, jika Anda menekan enter, itu tidak akan menunggu, itu hanya akan menjalankannya. Sama seperti sekarang dengan else atas. Anda dapat menekan shift + enter untuk mengetiknya di konsol (bila Anda memiliki PSReadLine).

PSReadline tidak mengacaukan klik kanan, meskipun ada kasus sudut di mana karakter TAB berkembang menjadi sesuatu yang tidak akan ada tanpa PSReadline - tetapi itu lebih berkaitan dengan bagaimana input multi-baris tidak berfungsi sebagai diharapkan jika Anda tidak menggunakan PSReadline.

Tapi maksud saya sebenarnya lebih sederhana - pengalaman interaktif dimaksudkan untuk sedekat mungkin, idealnya identik, dengan menempatkan teks yang sama dalam sebuah skrip. Fitur ini akan menyimpang dari maksud itu dalam skenario yang umum digunakan - klik kanan.

Pada titik ini, saya mengatakan membuat penilaian dengan satu atau lain cara atas saran ini, saya hanya menunjukkan sesuatu yang mungkin tidak jelas bagi semua orang.

Klik kanan-tempel dapat menggunakan beberapa modernisasi, menempelkan seluruh buffer clipboard ke konsol seolah-olah Anda telah menggeser + memasuki setiap baris dan kemudian menjalankannya seperti itu. Bahkan tanpa mempertimbangkan masalah ini, saya pikir itu akan berguna dengan sendirinya -- berapa kali Anda mengklik kanan-menempelkan sesuatu yang tidak benar (mengurai kesalahan) dan melihat banyak pesan kesalahan, mungkin diselingi dengan beberapa perintah yang dieksekusi? Itu bisa sangat berbahaya, tergantung pada apa yang Anda tempel (oops, perintah cd itu tidak diurai dengan benar, jadi saya tetap berada di direktori C:\ saya saat ini ketika perintah del *.* -r -fo dijalankan. ..). Akan lebih baik jika klik kanan-tempel benar-benar menempelkan seluruh blok, dan PowerShell sudah menanganinya dengan baik di sisi eksekusi.

Secara teknis, pengalaman interaktif saat ini sudah berbeda dengan menempatkan teks yang sama dalam skrip karena klik kanan-tempel menjalankan perintah saat ditempelkan, bukan sebagai kumpulan perintah. Hasilnya adalah kesalahan penguraian tidak mencegah eksekusi parsial di klik kanan-tempel saat mereka melakukannya di skrip.

Juga, untuk PowerShell ad-hoc yang interaktif, saya pikir sangat jarang bagi pengguna untuk memasukkan perintah multi-baris dengan mengetiknya di konsol, dan bagi pengguna yang melakukannya hari ini, mereka dapat terus melakukannya seperti biasanya. selesai. Bagi kita orang normal lainnya, saluran pipa kita akan berada pada satu baris kecuali kita mengklik kanan-tempel, yang seperti yang ditunjukkan di atas, dapat, dan mungkin harus, ditingkatkan sehingga pengalaman interaktif benar-benar sedekat mungkin. , idealnya identik, untuk menempatkan teks yang sama dalam skrip.

Semua untuk mengatakan: +1 karena memiliki saluran pipa dukungan PowerShell di awal baris tanpa karakter kelanjutan baris, dan permintaan untuk memperbaiki tempel-klik kanan sehingga ada konsistensi yang lebih baik antara penggunaan interaktif dan pengalaman pembuatan skrip.

Klik kanan bukan fitur PowerShell, ini adalah fitur conhost. Conhost tidak dapat selalu menganggap simulasi pengetikan setara dengan menempelkan tanpa koordinasi dengan proses konsol saat ini.

Ya. Mungkin membuat tempel klik kanan menjadi canggung. Dengan cara yang persis sama dengan else .

Ini akan membuat perintah (baik di konsol dan di file) dengan banyak pipa jauh lebih mudah dibaca dan, seperti yang ditunjukkan sebelumnya, memiliki masalah yang persis sama dengan if/else ketika dijalankan di Prompt.

Hingga saat ini sebuah | sebagai karakter terakhir pada sebuah baris telah berfungsi sebagai karakter lanjutan. Apa yang dibawa perubahan ini terutama jika itu menghentikan perilaku sebelumnya yang berfungsi?

Dikirim dari iPad saya

Pada 8 Mar 2017, pukul 17:04, Michael T Lombardi < [email protected] [email protected] > menulis:

Ini akan membuat perintah (baik di konsol dan di file) dengan banyak pipa jauh lebih mudah dibaca dan, seperti yang ditunjukkan sebelumnya, memiliki masalah yang persis sama dengan if/else ketika dijalankan di Prompt.

—
Anda menerima ini karena Anda berlangganan utas ini.
Balas email ini secara langsung, lihat di GitHub https://github.com/PowerShell/PowerShell/issues/3020#issuecomment-285101638 , atau nonaktifkan utas https://github.com/notifications/unsubscribe-auth/AHgYUW- mDh_8nDUr671LdathDzLZPhS7ks5rjt9-gaJpZM4LohkD .

Apakah perubahan ini mengharuskan | masih tidak bisa menjadi karakter lanjutan di EOL _serta_ di awal baris baru? Saya tidak akan mengharapkannya.

@RichardSiddaway ini tentang keterbacaan - ini telah muncul beberapa kali dalam diskusi tentang pembungkusan baris dalam praktik & repo gaya. Beberapa orang sudah menulis dengan cara ini, hanya menggunakan backticks di akhir baris.

Memiliki karakter pipa sebagai hal pertama di baris membuatnya _benar-benar_ jelas bahwa ini adalah kelanjutan --lebih dari sekadar membuat indentasi-- terutama jika garisnya panjang dan Anda tidak dapat dengan mudah melihat pipa di ujungnya.

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

vs.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

@jaykul dalam contoh Anda di atas lekukan sama bergunanya dari perspektif ketajaman visual. Simbol pipa tampaknya hanya indikator tambahan (dan IMO tidak diperlukan).
dengan contoh Anda, apakah ini menarik bagi Anda?

Get-Process | Where CPU | Where Path
|Get-Item | Where FullName -match "AppData"
|Sort FullName -Unique

Bagi saya, ini tampaknya cukup bisa dimengerti:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" |
    Sort FullName -Unique

ini adalah lekukan yang membantu (dan biasanya saya menulis ini)

FWIW, saya tidak pernah mengerti penggunaan backtick di saluran pipa yang panjang dan mencoba menekannya setiap kali saya melihatnya di ulasan kode, karena itu tidak dibutuhkan.

Saya secara eksplisit lebih suka pipa sebagai karakter pertama, seperti pada contoh pertama Anda, @JamesWTruher (walaupun dengan satu spasi antara pipa dan karakter pertama dari perintah) - ini memberikan indikator visual yang sangat jelas dan eksplisit dari pipa yang berkelanjutan . Lekukan memberikan kesimpulan yang serupa, tetapi kurang eksplisit, saat menggulir kode.

@Jaykul Ini benar-benar akan mematahkan pengalaman baris perintah interaktif. Misalnya, Anda mengetik perintah dan tekan kembali

PS> dir
>

Apakah Anda mendapatkan keluaran? Tidak, jangan karena parser sedang menunggu token berikutnya yang _mungkin_ merupakan kelanjutan. Sekarang tekan tombol kembali. Tidak ada yang terjadi kecuali Anda melihat lebih banyak perintah karena pengurai masih menunggu token untuk melihat apakah itu merupakan kelanjutan.

PS> dir
>
>

OK - tambahkan | sort Length dan tekan kembali.

PS> dir
>
>
> | sort Length
>

Dan masih tidak ada yang terjadi karena _masih_ mungkin ada token lanjutan sehingga masih harus mendengarkan baris baru. Sekarang Anda mengatakan 'saya sudah selesai dengan ini - itu tidak berhasil, mari kita dapatkan tanggalnya'. Anda mengetik Get-Date dan tekan kembali. Yay - Anda mendapatkan output. Tapi itu bukan dari Get-Date . Tidak - Anda akhirnya menyelesaikan perintah dir | sort Length jadi ini adalah output yang Anda lihat. Sementara itu, pembaca perintah sekarang menunggu Anda untuk menyelesaikan perintah yang Anda mulai dengan Get-Date . Atau semuanya mungkin hanya kesalahan.

Ini akan menjadi pengalaman interaktif yang mengerikan bagi setiap pengguna.

Bisakah kita membuatnya bekerja hanya dalam file? Ya - mungkin tetapi seperti yang disebutkan @lzybkr , salah satu prinsip desain dasar kami adalah bahwa apa yang berfungsi pada baris perintah dapat dengan mudah ditempelkan ke dalam file dan sebaliknya. Kami bahkan mendukung penempelan dari dokumen Word dengan karakter emdash dan endash.

Jadi sementara saya benar-benar suka bagaimana '|' melihat awal baris dalam hal-hal seperti pencocokan pola Haskell:
fib n | n == 0 = 1 | n == 1 = 1 | n >= 2 = fib (n-1) + fib (n-2)
itu tidak akan berfungsi untuk PowerShell.

Dengan peringatan bahwa saya sebagai bayi yang baru lahir dalam hal internal, berikut adalah beberapa pengamatan:

# This works everywhere
Get-Process |
Select-Object -First 1

# This errors at the prompt unless using soft returns, note the two blank lines;
# hitting enter after the first one causes it to error out.
# Note that with soft returns you can go just about forever before adding the next line.
Get-Process |


Select-Object -First 1

# This will run fine in either
If ($false) {
  ' False Output'
} Else {
  'True Output'
}
# This will error in the prompt (unless using soft returns) but pass in a file
If ($false) { 'False Output' }
Else { 'True Output' }

Selain itu, saya berharap/baik-baik saja dengan kegagalan berikut di Prompt tanpa pengembalian lunak, seperti yang dilakukan if/else yang tidak dipeluk:

Get-Process
| Select-Object -First 1

Saya tidak terlalu peduli dengan keterbacaan, terutama keterbacaan sekilas, ketika interaktif pada Prompt (karena, umumnya, saya menulisnya beberapa saat yang lalu) tetapi itu salah satu perhatian utama saya ketika saya sedang menulis/mempertahankan skrip dan modul atau men-debug pekerjaan orang lain, dll.

Untuk mengatasi @JamesWTruher - saya berharap orang tidak akan membuat indentasi garis lanjutan jika pipa ada di depan sebagai indikasi apa yang terjadi:

Get-Process | Where CPU | Where Path
| Get-Item | Where FullName -match "AppData"
| Sort-Object FullName -Unique # I'm so proud of this highlighting "bug" by the way

@BrucePay Jadi, benar. Pengalaman interaktif tidak akan _secara eksplisit_ mendukungnya.

Jika kalian benar-benar berpikir tidak ada perbedaan antara interaktif dan skrip, _Anda perlu mencoba menggunakan PowerShell tanpa PSReadLine sesekali_.

Coba gunakan konsol di ISE atau VS Code

Kecuali jika Anda memiliki PSReadline untuk menangani pengecualian tipe "blok pernyataan yang hilang" atau "elemen pipa kosong", Anda tidak dapat meletakkan baris baru setelah pipa, atau menulis kurung kurawal gaya Allman. Anda tentu tidak dapat menulis salah satu dari ini:

Get-Process |
Where CPU

if($True)
{



md5-9d813a39f05f47b572d1068b0164b382



Or whether I will write the (necessary) generic `catch { "You threw $_" }` handler after



md5-6b461006504b741b884d4fb3f126b489



And it won't let me put a comment where it thinks there should be code, so neither of these is possible:



md5-adc435ab733361316365acfc69de09df



```posh
Get-Process |
# I only want actual apps, with windows
Where MainWindowHandle

Jadi ya, ini akan menjadi _tempat lain_ di mana Anda dapat memiliki jeda baris dalam skrip tetapi tidak di konsol. Tapi kami sudah memiliki banyak (_terutama_ jika Anda tidak menggunakan PSReadLine).

Untuk referensi kode yang dimiliki @Jaykul 1 dan @JamesWTruher 2 , saya menggunakan ini:

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

Seperti yang ditunjukkan, lekukan membuat ini lebih mudah dibaca ketika memindai kode dengan cepat - saya tahu ketiga baris kode itu 'diikat' bersama tanpa harus melirik ke ujung untuk melihat pipa. Keterbacaan bagi saya adalah salah satu hal terpenting ketika saya menulis kode.

Saya terkadang menambahkan karakter backtick ke akhir setelah pipa, tetapi ketika saya ingat _itu tidak diperlukan_, saya menandai diri saya sendiri untuk itu. Ini adalah kebiasaan yang saya coba hentikan (backtick bukan briching).

Menyalin dan menempel ke konsol dengan PSReadline tidak memberi saya masalah (saya ingat) jadi itu bukan sesuatu yang akan saya bahas dan tambahkan ke diskusi.

Memiliki pipa di baris berikutnya alih-alih di ujung baris adalah ide yang sangat mirip F#, di mana Anda dapat melakukan hal-hal seperti ini:

F# let f1 str server = str |> parseUserName |> getUserByName server |> validateLogin <| DateTime.Now

Dan saya siap untuk apa pun yang membuat PS sedikit lebih fungsional (permainan kata-kata) ;)

Bukan hanya F# tetapi juga Elm , Haskell , Elixir , dan bahkan panduan gaya shell Google (dan perhatikan di sini mereka harus keluar dari baris baru untuk melakukannya ...).

@michaeltlombardi Seperti halnya shell Unix, Anda dapat keluar dari baris baru di PowerShell jika Anda mau

Get-Process | Where CPU | Where Path `
| Get-Item | Where FullName -match "AppData" `
| Sort-Object FullName -Unique

F# peka terhadap spasi (aturan offside) dengan cara yang tidak dilakukan PowerShell. Elm, Haskell, dan Elixir, tentu saja, bukan cangkang.

_keluhan tentang host yang buruk_...

Interpreter memberikan informasi ke aplikasi host dengan melemparkan pengecualian IncompleteParse . Terserah implementasi Host untuk menangkap ini dan meminta lebih banyak masukan. Jika tuan rumah melakukan kesalahan ini, adukan kepada pemilik tuan rumah.

Jika kalian benar-benar berpikir tidak ada perbedaan antara interaktif dan skrip, Anda perlu mencoba menggunakan PowerShell tanpa PSReadLine sesekali.

Saya menggunakan PowerShell selama lebih dari satu dekade tanpa PSReadLine. Apa itu cukup?

Kesalahan ini pada prompt kecuali menggunakan pengembalian lunak, perhatikan dua baris kosong;

Bagaimana itu ditangani tergantung pada implementasi Host. Buka masalah pada host yang menyinggung jika Anda ingin ini diubah.

masalah yang sama persis seperti yang dilakukan if/else ketika dijalankan di Prompt.

Ya. Ini ambigu. Maaf. Saya tidak bisa memikirkan cara untuk membuatnya bekerja dengan andal. Jika kita menggunakan OTBS alih-alih mencocokkan gaya penjepit C#, ini tidak akan signifikan. Sebenarnya akan ada banyak keuntungan menggunakan OTBS (misalnya DSL). Perhatikan juga: di Host konsol asli, ini "berfungsi" karena setelah menerima pengecualian IncompleteParse , Host terus membaca baris hingga mencapai baris kosong, lalu mengeksekusi hasilnya. Tapi ini berarti Anda selalu harus menekan baris baru ekstra.

@Jaykul Jadi, apakah Anda ingin kebalikan dari #light directive F#? Sesuatu seperti #heavy di mana spasi tidak relevan dan titik koma wajib?

Melarikan diri dari baris baru di PS, menurut saya, lebih bermasalah daripada kebanyakan bahasa. Karakter pelarian PS adalah backtick sialan. Penyorotan sintaks tidak terlalu menonjolkan sebagian besar -- sebagian besar skema sorotan membuatnya menjadi warna yang cukup membosankan.

Tambahkan ke fakta bahwa ketika Anda kembali dan mengedit sesuatu yang penuh dengan backtick, kemungkinan Anda akan secara tidak sengaja melewatkan satu atau dua backtick yang salah tempat di tengah-tengah pengeditan cukup tinggi.

Saya akan menggunakan formulir itu jika melacak kesalahan backtick tidak seperti menemukan jarum di tumpukan jerami. Tidak, saya pikir akan lebih baik untuk mengizinkan format pipa di awal sebagai gaya dalam dirinya sendiri, tanpa mewajibkan untuk keluar dari garis. :/

@vexx32 Sementara saya setuju bahwa '''' sulit dilihat, '|' tidak.

@Jaykul Jadi, apakah Anda ingin kebalikan dari #light directive F#? Sesuatu seperti #heavy di mana spasi tidak relevan dan titik koma wajib?

Tidak @BrucePay , saya hanya ingin trik sintaks lain seperti ini:

try { throw 5 }
catch [ArgumentException] {  <# ... #> }
catch { Write-Warning Whatever }

yang memungkinkan saya menulis sesuatu dengan _rapi_ dalam skrip, tanpa khawatir apakah itu berfungsi saat Anda mengetik di konsol atau tidak.

@BrucePay benar, dan saya memiliki beberapa kode menggunakan backticks itu, tetapi yang kami cari di sini adalah kemampuan untuk menulis kode tanpa mereka karena semua alasan @vexx32 terdaftar.

Sangat adil untuk menunjukkan bahwa beberapa perilaku yang ada di PowerShell yang diandalkan orang sebenarnya adalah hasil dari implementasi host, jadi terima kasih telah mengklarifikasi hal-hal itu! Di sisi lain, ini juga menyiratkan bahwa ada hal-hal dalam bahasa yang sudah mematahkan harapan itu kecuali implementasi Host melakukan pekerjaan ekstra untuk menanganinya, bukan?

@michaeltlombardi Implementasi host yang buruk akan menghasilkan pengalaman interaktif yang buruk tetapi tidak memengaruhi bahasa itu sendiri. Yang mengatakan, pengalaman interaktif sangat penting karena sebagian besar 'skrip' PowerShell diketik secara interaktif.

yang kami cari di sini adalah kemampuan untuk menulis kode tanpa mereka

Maksud saya adalah jika Anda meletakkan | di akhir baris, kelanjutannya tersirat dan tidak diperlukan karakter lanjutan seperti yang Anda minta. Dan simbol | mudah dilihat. Dan gunakan lekukan untuk membuat struktur kode terlihat jelas. Tidak seperti F# atau Python, kami tidak menerapkan indentasi karena PowerShell adalah shell dan terkadang Anda perlu menulis kode yang sangat padat.

@Jaykul

tanpa khawatir apakah itu berfungsi saat Anda mengetik di konsol atau tidak.

Pengalaman konsol tetap menjadi skenario utama bagi kami dan sebagian besar pelanggan kami. Namun kami memiliki fitur meta yang akan datang untuk mendukung fitur eksperimental. Kami dapat mencoba melakukan apa yang Anda inginkan, diekspos sebagai fitur eksperimental, dan kemudian melihat umpan balik seperti apa yang kami dapatkan tentang keseluruhan pengalaman.

Saya benar-benar mengerti bahwa pengalaman konsol adalah yang utama. Maksud saya hanyalah bahwa ini tidak boleh merusak konsol, seperti yang Anda sarankan dalam komentar _first_ Anda.

Itu harus berperilaku di konsol _dengan cara yang sama_ yang dilakukan catch atas: Anda hanya dapat mengetiknya di konsol tempat Anda memiliki ReadLine multi-baris seperti PSReadLine dan dapat Shift+Enter untuk menyuntikkan baris tambahan (atau Anda dapat menempelkannya) -- tidak perlu mengubah perilaku yang ada sama sekali.

Bagaimanapun, ini adalah fitur yang ditujukan untuk meningkatkan pemformatan kode, bukan mengurangi pengetikan. Itu perlu bekerja dalam pengalaman skrip, bukan konsol interaktif.

Tetapi salah satu janji yang kami buat kepada pengguna sejak awal adalah Anda dapat menempelkan dari skrip (contoh, dll.) ke konsol dan membuatnya berfungsi. Ini bahkan termasuk menempelkan dari dokumen Word dengan emdash, dll. Salin dan tempel sejauh ini merupakan bentuk penggunaan kembali yang paling umum (kami melakukan penelitian untuk memvalidasi ini)

Benar. Tetapi hal salin-tempel saat ini hanya _sepenuhnya_ benar hanya selama Anda menempelkan ke Ctrl+V PSReadLine dan bukan melalui klik kanan -- dan perubahan ini juga akan berfungsi di sana. Artinya, itu akan membutuhkan ReadLine yang mampu menempel multi-baris, tetapi itu akan berfungsi secara default di PowerShell 5+

Seperti yang saya sebutkan di atas , ada beberapa kasus (jika/lain, coba/tangkap, komentar, kawat gigi Allman, dll) di mana itu _sudah_ tidak terjadi jika Anda _tidak_ memiliki PSReadLine.

Pendapat saya adalah bahwa satu kasus tepi lagi ke daftar masalah dengan host non-PSReadLine bukanlah alasan yang cukup besar untuk mengecualikan fitur -- lagi pula, sintaks ini tidak akan berfungsi di PowerShell 4 atau 5, jadi ' tidak akan pernah berfungsi di ISE atau host non-PSReadline. Ini _membuat saya sedikit gila_ bahwa kami menghabiskan banyak upaya untuk memperdebatkan satu _lebih_ masalah dengan menempelkan ke {{not-our-problem}} tetapi kami setuju dengan fakta bahwa itu adalah sintaks yang tidak berfungsi di versi yang lebih lama versi PowerShell...

PS Saya telah menggunakan argumen tempel sebagai salah satu pembenaran untuk Praktik Terbaik memilih OTBS daripada Stroustrup atau Allman , tapi saya pasti akan merujuk utas ini di buku sekarang 😁

Saya _sangat_ berharap kami pergi dengan OTBS. DSL akan jauh lebih sederhana.

OTBS, tentu saja, adalah satu-satunya cara yang benar....

@BrucePay - Saya yakin masih ada beberapa orang yang menempelkan baris perintah multi-baris dan tidak menggunakan Ctrl+v , tapi saya rasa tidak banyak orang, dan mereka harus beradaptasi, menempel tanpa klik kanan atau Alt+Spacebar ,e,p lebih unggul dalam banyak hal.

Saya pikir sangat masuk akal untuk mempertimbangkan perubahan ini.

Adakah yang bisa mengarahkan saya ke arah yang benar untuk apa yang perlu terjadi agar ini berhasil? Saya ingin setidaknya membuatnya berfungsi dan melihat seperti apa ... dan kemudian mungkin meletakkannya di belakang bendera eksperimental sehingga kami dapat mengujinya sedikit jika perlu -- tetapi sejujurnya saya bahkan tidak yakin apakah itu sangat diperlukan; lagi pula, ini tidak akan secara terang-terangan mengubah apa pun tentang pengalaman saat ini, cukup tambahkan yang baru.

Mengingat bahwa elemen pipa apa adanya di awal baris adalah kesalahan instan saat ini, itu bukan pola pengkodean yang sedang diikuti tanpa juga penggunaan baris baru yang lolos, yang juga tidak akan terpengaruh dengan membuat perubahan ini. Jadi sungguh... tidak ada ruginya di sini, semuanya untung?

Ini mungkin tidak akan berhasil, tetapi Anda harus memulai:

diff --git a/src/System.Management.Automation/engine/parser/Parser.cs b/src/System.Management.Automation/engine/parser/Parser.cs
index a31f64fa0..37b897f7c 100644
--- a/src/System.Management.Automation/engine/parser/Parser.cs
+++ b/src/System.Management.Automation/engine/parser/Parser.cs
@@ -5653,6 +5653,11 @@ namespace System.Management.Automation.Language
                 }

                 pipeToken = PeekToken();
+                if (pipeToken.Kind == TokenKind.Newline)
+                {
+                    SkipNewlines();
+                    pipeToken = PeekToken();
+                }

                 switch (pipeToken.Kind)
                 {

Anda benar, itu tidak cukup sampai di sana. Setidaknya sebagian karena saat ini parser tidak peduli dengan jumlah baris baru; begitu banyak pernyataan tidak pernah dieksekusi . Saya memiliki beberapa pemikiran potensial tentang bagaimana melanjutkan, jadi Anda telah memberi saya teka-teki yang menarik, terima kasih! 💖

Utas seperti ini benar-benar menunjukkan manfaat luar biasa yang dibawa oleh sumber terbuka PowerShell kepada kita dan bagi kita semua untuk dapat berdiskusi dengan baik dan terbuka dengan Tim Produk, MVP, anggota komunitas tepercaya, dan mereka yang baru mengenal bahasa seperti ini. fantastis. Hanya mengutip tanggapan @Jaykul sebelumnya di utas ini, ini akan menjadi tujuan akhir yang ideal.

Bagian penting dari apa yang dikatakan @Jaykul di atas adalah bahwa kita cenderung lebih mudah memahami dan membaca bahwa kelanjutan dari suatu perintah ada di awal baris daripada di akhir baris

@RichardSiddaway ini tentang keterbacaan - ini telah muncul beberapa kali dalam diskusi tentang pembungkusan baris dalam praktik & repo gaya. Beberapa orang sudah menulis dengan cara ini, hanya menggunakan backticks di akhir baris.

Memiliki karakter pipa sebagai hal pertama di baris membuatnya _benar-benar_ jelas bahwa ini adalah kelanjutan --lebih dari sekadar membuat indentasi-- terutama jika garisnya panjang dan Anda tidak dapat dengan mudah melihat pipa di ujungnya.

Get-Process | Where CPU | Where Path |
    Get-Item | Where FullName -match "AppData" | 
    Sort FullName -Unique

vs.

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

Jadi ya, saya ingin bisa melakukan ini di masa depan

Get-Process | Where CPU | Where Path
    | Get-Item | Where FullName -match "AppData"
    | Sort FullName -Unique

Saya perlu memberikan ini upaya lain di beberapa titik segera. Ini adalah teka-teki yang menarik, tetapi belum ada yang benar-benar saya ketahui cara memecahkannya. 😕

Saya setuju dengan kedua @kilasuit karena ini luar biasa, kami sekarang memiliki PowerShell versi open source. Selain itu, saya menginstalnya di Manjaro Linux kemarin dan sedikit kagum karena ia membangun semuanya dari awal. Dan begitu cepat.

Saya juga setuju dengan @RichardSiddaway bahwa akan lebih baik untuk dapat memiliki _option_ menggunakan karakter kelanjutan baris di awal baris. Saya seorang pendukung besar dalam pengkodean untuk keterbacaan sehingga lekukan (yaitu. opsi pertama) adalah apa yang saya gunakan dan saya senang dengannya. Saya sebenarnya tidak suka tampilan opsi kedua (saya pikir itu terlihat jelek :)) tetapi itu menghilangkan ambiguitas. Dan saya mendukung orang-orang yang memiliki pilihan jika itu meningkatkan keterbacaan!

Tadi malam saya merasa ingin mengutak-atik parser, dan ini selalu mengganggu saya ( saya selalu lebih suka pipa di awal baris ). Inilah hasilnya:

Satu-satunya pertanyaan yang saya miliki adalah apakah ini perlu disembunyikan di balik bendera eksperimental atau tidak. Jika tesnya cukup, mengapa membuatnya eksperimental sama sekali, karena tidak memengaruhi fungsionalitas yang ada? Pikiran?

Sekarang untuk membungkusnya dalam beberapa tes Pester ...

Saya tidak berpikir itu benar-benar membutuhkan tanda eksperimental, asalkan perilakunya dapat diprediksi, konsisten, dan dapat diuji. Itu tidak melanggar perilaku yang sudah ada sebelumnya sejauh yang saya tahu.

Sepertinya juga tidak ada perselisihan mengenai desainnya.

Juga sebagai catatan tambahan, sangat disayangkan bahwa PowerShell mengizinkan nama perintah dimulai dengan "-". Kalau tidak, kita mungkin bisa membungkus parameter pada baris baru tanpa backticks juga. Tentu kami memiliki percikan, tetapi ini dapat bekerja _dengan Intellisense dan Penyorotan Sintaks_ jika nama perintah tidak cocok dengan nama parameter:

Get-AzureRmAppServicePlanMetrics
    -ResourceGroupName Default-Web-WestUS
    -Name ContosoWebApp
    -StartTime 2016-11-30T22:00:00Z
    -EndTime 2016-11-30T22:30:00Z
    -Granularity PT1M
    -Metrics Requests

Saya sedang menunggu sekuel seperti percikan, tapi pasti berpikir pilihan untuk memilikinya sebagai karakter pertama sangat bagus. Tentu itu berbeda antara interaktif dan skrip, tetapi itu konsisten dengan bagaimana PowerShell sudah ada.

Satu-satunya pertanyaan yang saya miliki adalah apakah ini perlu disembunyikan di balik bendera eksperimental atau tidak. Jika tesnya cukup, mengapa membuatnya eksperimental sama sekali, karena tidak memengaruhi fungsionalitas yang ada? Pikiran?

Saya tidak tahu mengapa tim MSFT sangat pasif pada saat terakhir tetapi jika kode Anda akan berada di bawah tag eksperimental, saya dapat meninjau dengan cepat. Kami juga dapat mengaktifkan fitur secara default di powershell.config.json.

sayang sekali PowerShell mengizinkan nama perintah dimulai dengan "-".

Saya setuju penuh. Saya pikir itu layak untuk dibahas secara menyeluruh dalam edisi baru. (Ada karakter lain yang bisa kita singkirkan.)

"Elemen pipa kosong tidak diperbolehkan", jadi seharusnya tidak ada masalah kompatibilitas putus jika pipa digunakan untuk kelanjutan jalur dan awal baris berikutnya, pada saat yang sama:

Get-Process | Where CPU | Where Path |
    | Get-Item | Where FullName -match "AppData" |
    | Sort FullName -Unique

Yang menangani banyak keluhan - tidak ada backtick, pipa di awal baris untuk indikasi visual kontinuitas; tidak ada perubahan pada perilaku prompt interaktif setelah mengetik baris pertama karena dapat mengetahui apakah akan mengharapkan baris lanjutan; tidak memiliki banyak kebingungan dengan operator || dicadangkan karena dibagi menjadi beberapa baris; tidak lebih mengetik daripada menggunakan backtick dan pipa; tidak perlu memiliki masalah dengan baris komentar di antaranya sesuai contoh if/else , try/catch Jaykul.

@HumanEquivalentUnit - Saya tidak dapat mengatakan bahwa saya adalah penggemar saran itu karena saya sebagai penulis skrip dapat memutuskan bahwa saya ingin menghapus baris baru dalam skrip untuk penggunaan cmdline dan akan dibiarkan dengan satu baris yang tidak dapat dijalankan dan tidak intuitif IMO itu
terlihat mengerikan

Get-Process | Where CPU | Where Path |    | Get-Item | Where FullName -match "AppData" |    | Sort FullName -Unique

Yang

@kilasuit bahwa baris yang diedit terlihat aneh (tidak terlihat mengerikan bagi saya, hanya aneh), tetapi apakah itu benar-benar berbeda dari kode dengan backticks yang valid sekarang, jika Anda menghapus baris tanpa menghapus kelanjutan baris? Apakah Anda saat ini menderita masalah dengan kode backtick?

Get-Process | Where CPU | Where Path `    | Get-Item | Where FullName -match "AppData" `    | Sort FullName -Unique

Jika Anda bertanya kepada saya, itu hanya alasan yang jelas mengapa PR Kirk diterima, jujur. Tidak memerlukan backtick atau pipa tambahan sangat rapi saat mengondensasi saluran.

Permintaan awal dilaksanakan.
Sekarang kita bahas https://github.com/PowerShell/PowerShell-RFC/pull/179