Alternatif saat ini memaksa pengguna untuk menormalkan jalur

PowerShell sudah bekerja untuk Anda dan Anda tidak perlu menormalkan jalur.
PowerShell sangat ramah pengguna di sini - pengguna dapat menggunakan garis miring yang nyaman bagi mereka terlepas dari platformnya.
Praktik terbaik adalah menghindari penggunaan jalur literal dan menggunakan cmdlet jalur.

Praktik terbaik adalah menghindari penggunaan jalur literal dan menggunakan cmdlet jalur.

@iSazonov Ya dan tidak.

Tentu, jika Anda menggabungkan segmen jalur, Anda dapat menggunakan cmdlet jalur. Tetapi jika Anda menulis skrip yang mereferensikan jalur relatif dengan banyak segmen, dan jika Anda bermaksud agar skrip Anda berfungsi lintas platform, Anda tidak akan melakukannya.

Di PowerShell 7 preview 3 di Windows, penyelesaian tab menyelesaikan jalur menggunakan garis miring terbalik. Itulah satu-satunya tempat di mana saya pikir kita melakukan kesalahan sekarang karena PowerShell adalah lintas platform. Setidaknya harus ada opsi untuk memilih karakter pemisah direktori yang ingin Anda gunakan di Windows sebagai bagian dari penyelesaian tab: [System.IO.Path]::DirectorySeparatorChar atau [System.IO.Path]::AltDirectorySeparatorChar . Mengingat di mana kita berada hari ini, saya menduga kebanyakan orang yang melakukan pekerjaan lintas platform ingin penyelesaian tab dari jalur untuk menggunakan AltDirectorySeparatorChar pada Windows secara default, tetapi sejauh yang saya tahu tidak ada cara untuk membuatnya melakukan itu .

@chriskuech : Selain penyelesaian tab jalur, apakah ada tempat lain di mana Anda merasa AltDirectorySeparatorChar tidak digunakan di mana Anda ingin memiliki opsi untuk menggunakannya daripada DirectorySeparatorChar ? Saya tidak bisa memikirkan apapun.

@KirkMunro , apakah Anda mengatakan bahwa ada (setidaknya sebagian diimplementasikan) cara untuk menormalkan jalur di PowerShell hari ini? Jika demikian, apakah ini akan berfungsi pada 6.x terbaru? Kasus penggunaan yang saya hadapi adalah variabel otomatis dan perintah *-Path .

@iSazonov , solusi yang diusulkan tidak akan berfungsi untuk skenario saya karena saya membuat daftar jalur di Windows, membuat daftar jalur di Linux, kemudian mencoba membandingkannya, yang gagal karena pemisah.

Variabel otomatis secara konsisten tidak memiliki pemisah direktori tambahan, sehingga PowerShell dengan indah memungkinkan pembuatan jalur dengan literal. Mantan:

$RepoRoot = "$PSScriptRoot/../.."
$SourceRoot = "$RepoRoot/src"
$BuildRoot = "$RepoRoot/.build"

Saya pikir ini jauh lebih jelas daripada

$RepoRoot = Join-Path $PSScriptRoot "../.."
$SourceRoot = Join-Path $RepoRoot "src"
$BuildRoot = Join-Path $RepoRoot ".build"

jadi saya harap ini bisa berfungsi di masa depan, meskipun tidak secara default.

@chriskuech kebiasaan pribadi saya telah menjadi seperti:

$SourceRoot = $RepoRoot | Join-Path -ChildPath 'src'

Ini sedikit lebih jelas tapi ya itu tidak sempurna.

Join-Path memiliki AdditionalChildPath yang menerima array string.

@chriskuech Terima kasih atas informasi tambahannya.

Saya tidak menyarankan bahwa PowerShell mendukung sebagian normalisasi jalur. Saya hanya menyebut bahwa saya pribadi tidak menyukai penyelesaian tab yang menggunakan garis miring mundur secara default pada Windows, dan garis miring secara default di Linux atau macOS.

Jika saya dapat mengubah beberapa pengaturan untuk mengubahnya sehingga garis miring digunakan bahkan pada jalur Windows secara default, saya akan membuat perubahan itu, dan ini adalah satu tempat di mana saya pikir mungkin ada peluang untuk membuat PowerShell lintas platform bekerja lebih mudah. Join-Path menggunakan [System.IO.Path]::DirectorySeparatorChar sebagai pemisah jalur juga. Idealnya jika ada pengaturan untuk mengatur pemisah jalur yang diinginkan saat menulis skrip (karena kita harus dapat dengan mudah menulis skrip seperti yang kita inginkan terlepas dari platform yang kita pilih untuk menulisnya), itu akan tercermin dalam penyelesaian kedua tab dari jalur dan Join-Path juga.

Selain kebutuhan pribadi itu, saya ingin tahu apakah cmdlet Compare-Path akan berguna. Itu bisa menormalkan pemisah jalur, dan bahkan membandingkan jalur absolut dengan jalur relatif dengan menyelesaikan jalur relatif sebelum perbandingan dibuat jika salah satu jalurnya absolut.

Ya, kami mendapatkan normalisasi _platform-specific_ di Convert-Path dan Resolve-Path :

PS> Convert-Path C:/Windows
C:\Windows # normalized to Windows-native "\"

Jadi, mungkin sebagai alternatif untuk memperkenalkan cmdlet Compare-Path , Convert-Path dan Resolve-Path dapat diperluas untuk mendukung sakelar -UseSlash (nama dapat dinegosiasikan).

Secara terpisah dan saling melengkapi, mekanisme preferensi keikutsertaan untuk menggunakan / di Windows yang disarankan Kirk kemudian dapat juga berlaku untuk Convert-Path dan Resolve-Path (selain penyelesaian tab dan Join-Path ).

Tangkapannya saat ini adalah bahwa Convert-Path dan Resolve-Path hanya bekerja dengan jalur _existing_, tapi itu adalah sesuatu yang layak diubah dengan sendirinya, seperti yang disarankan @jaykul beberapa waktu lalu - lihat #2993

Saya pikir akan lebih baik jika penyelesaian jalur menggunakan pemisah jalur yang muncul secara eksplisit dalam teks penyelesaian, dan jika tidak ada, maka default ke pemisah asli platform.

Jadi di Windows, c:\w selesai ke c:\Windows\ dan c:/w selesai ke 'c:/Windows/'.

Saya pikir ini akan mencakup sebagian besar gangguan tanpa memerlukan opsi konfigurasi, dan sebenarnya lebih disukai karena Anda kadang-kadang mungkin memerlukan formulir lain untuk alasan apa pun.

@lzybkr , saya suka idenya, juga mengingat kekhawatiran tentang solusi berbasis konfigurasi / preferensi-variabel yang tidak saya sebutkan: masalah pelingkupan; dengan pelingkupan _dynamic_ biasa, kode yang membuat asumsi tetap tentang pemisah jalur dapat rusak (yang memiliki gema https://github.com/PowerShell/PowerShell-RFC/issues/7).

@lzybkr dan kapan kedua garis miring digunakan? C:\Program Files/A -> ?

Begitu banyak opsi - acak, bergantian masing-masing, selalu garis miring b/c itu satu-satunya pemisah jalur yang benar, dll.

Lebih serius, mungkin hanya memilih yang terakhir digunakan, yang mungkin diketik oleh pengguna sedangkan yang lain mungkin tidak.

@lzybkr : Ada satu tangkapan, meskipun:

Jika Anda memulai _tanpa_ pemisah jalur, untuk mereferensikan file/folder di _direktori saat ini_, PowerShell harus membuat pilihan untuk Anda, setidaknya berdasarkan algoritme penyelesaian saat ini yang diperluas ke .\<filename> atau ./<filename> / .\<folder>\ atau ./<folder>/ , sesuai platform.

Untuk _files_ sebagai _arguments_, kita dapat menghindari masalah itu dengan memperluas fil menjadi hanya file , misalnya (tanpa awalan .\ / ./ ).

Namun:

• untuk _executables_ , awalan .\ / ./ yang ditambahkan secara otomatis adalah kenyamanan yang berharga jika tujuannya memang untuk mengeksekusi skrip yang terletak di direktori saat ini.

• untuk _directories_, demikian pula, memperluas ke sesuatu dengan _trailing path separator_ ( <folder>\ atau <folder>/ ) juga berharga.

Dalam kedua kasus, tidak ada tindakan pengguna yang menyiratkan pemisah yang disukai.

Yang mengatakan, mungkin solusinya adalah: jika Anda ingin mengontrol pemisah, _mulai secara manual dengan_ ./ atau .\ dan buat penyelesaian tab menghormati itu.

Masalah ini telah ditandai sebagai dijawab dan tidak ada aktivitas selama 1 hari . Itu telah ditutup untuk keperluan rumah tangga.

@iSazonov : Ini tidak benar-benar dijawab, dan harus dibuka kembali untuk memungkinkan diskusi yang sedang berlangsung untuk terus menyelesaikan ini. OP bahkan belum memiliki kesempatan untuk menanggapi pertanyaan yang diajukan kembali kepadanya.

Saya pikir saya menjawab semua pertanyaan itu kepada saya, tetapi beri tahu saya jika saya tidak melakukannya. Saya juga tidak yakin mengapa masalah ini ditutup. Itu tidak dimaksudkan sebagai utas diskusi, melainkan permintaan fitur.

Akar masalah yang dihadapi:

• Haruskah alat lintas platform memiliki perilaku non-lintas platform secara default?
• Jika demikian, haruskah ada cara untuk menjalankan PowerShell secara global dalam mode "lintas platform"?

Saya pikir memaksa pengembang untuk menormalkan string secara manual dengan cmdlet adalah langkah yang salah. Saya tidak melihat skenario di mana menggunakan / secara default akan menyebabkan masalah pada Windows karena PowerShell, seperti yang disebutkan sebelumnya, sangat baik dalam menangani kedua jenis garis miring. Kecuali ada yang bisa memberikan situasi menarik di mana ini akan menyebabkan kesalahan, mengapa tidak menggunakan / saja secara default? Mungkin masalah ini perlu dipindahkan ke RFC.

Karena semakin banyak orang bermigrasi ke cloud, semakin banyak orang mengembangkan kode PowerShell di Windows dan menjalankannya di Linux. Pasti akan ada titik di masa depan (jika belum berlalu) di mana jumlah pengguna yang lebih memilih perilaku lintas platform yang sebenarnya melebihi siapa pun yang merasa sangat ingin mempertahankan \ di Windows.

@chriskuech : Ya ampun, saya tidak secara khusus mengajukan pertanyaan kepada Anda. Saya ingin tahu apakah Anda merasa cmdlet Conpare-Path akan membantu Anda. Terlepas dari pertanyaan itu, saya juga ingin melihat opsi normalisasi.

@KirkMunro Saya tidak yakin Compare-Path akan membantu, karena dalam kasus penggunaan asli (membandingkan jalur di Linux dan Windows), sistem file root berbeda, jadi saya harus memanggil Resolve-Path -Relative . Pada saat itu kasus penggunaan perbandingan hanyalah satu baris: | ? {($_ -replace "\\", "/") -in $ExpectedPaths} .

Namun, saya sangat ragu untuk mendukung solusi berbasis cmdlet apa pun, karena tidak menyelesaikan masalah root dan akan melarang interpolasi string untuk jalur atau memerlukan perubahan kode untuk setiap definisi string jalur. Secara khusus, Compare-Path tidak akan memperbaiki semua jalur log saya dengan garis miring campuran.

@KirkMunro @mklement0 Masalah ini tidak terkunci dan semua orang dapat menarik komentar.
Kami memiliki banyak masalah tanpa komentar dan kemajuan baru. Status terbuka telah kehilangan maknanya.
Sebagai seorang pengelola, saya bermaksud untuk lebih menuntut guna mendorong diskusi menjadi spesifikasi yang lebih ketat yang dapat dengan mudah berubah menjadi PR.
Adapun masalah, itu berubah menjadi tak terbatas - permintaan awal adalah "gunakan garis miring di Windows", lalu "bandingkan jalur". Apa selanjutnya? Jarak jauh? Ini terbuka untuk melanjutkan tetapi akan ditutup.
Sementara hanya satu proposal nyata dari Jason di atas (untuk meningkatkan penyelesaian) dan kami dapat membuka masalah pelacakan dan menutupnya dengan PR nyata.

Agar jelas, masalahnya masih "gunakan garis miring di Windows". "Bandingkan jalur" hanya diangkat sebagai satu (dari banyak) contoh motivasi.

Usul
Terapkan perilaku lintas platform yang sebenarnya, di mana pembatas jalur default ke / pada semua platform kecuali pengguna melengkapi tab jalur yang sudah berisi \ . Saya berharap ini disembunyikan sebagai fitur eksperimental untuk saat ini, tetapi saya setidaknya harus dapat mengaktifkan fitur "memaksimalkan perilaku lintas platform" dalam kode saya untuk mengoptimalkan pengalaman dev Windows devs yang menargetkan Linux.

Jika ini tidak masuk akal, saya ingin tahu mengapa dan apakah ada dokumentasi yang memandu ketika desain PowerShell berbeda di seluruh platform.

@iSazonov : Pengelola repo PS tidak boleh meremehkan masalah pengguna tanpa diskusi. Anda awalnya menjawab tanpa meluangkan waktu untuk memahami kebutuhan OP, menandai masalah sebagai telah dijawab, tetapi masalah itu tidak diposting sebagai pertanyaan, itu diposting sebagai permintaan fitur, dan seperti yang dapat dilihat oleh diskusi itu jelas tidak dijawab".

Status terbuka telah kehilangan maknanya.

Siapa bilang? Itu sama sekali tidak benar. Masalah terbuka terbuka, dan masalah tertutup ditutup. Kedua perbedaan itu memiliki arti yang sangat jelas. Saya hanya melihat masalah tertutup jika itu milik saya dan saya ingin kembali untuk memeriksa sesuatu. Pada kesempatan langka saya mungkin pergi mencari masalah tertutup untuk diskusi tentang topik tertentu. Tetapi 90% atau lebih waktu saya dalam masalah adalah dalam masalah terbuka, sebagaimana mestinya. Satu-satunya hal yang mengaburkan batas antara keduanya dan membuat masalah terbuka kehilangan maknanya adalah menutupnya secara ringkas sebelum diselesaikan, seperti yang telah Anda lakukan dengan masalah ini.

(Diskusi) terbuka untuk dilanjutkan tetapi akan ditutup.

Berdasarkan pendekatan untuk mengelola masalah ini, Anda memaksa orang untuk kehilangan perbedaan antara terbuka dan tertutup, sehingga mereka harus mencari semua masalah daripada fokus pada masalah terbuka, yang berarti memeriksa masalah terbuka 2K ditambah masalah tertutup 4K untuk diskusi yang relevan dengan mereka daripada hanya berfokus pada isu-isu terbuka. Itu adalah strategi manajemen masalah yang rusak dan cacat.

Adapun masalah, itu berubah menjadi tak terbatas - permintaan awal adalah "gunakan garis miring di Windows", lalu "bandingkan jalur". Apa selanjutnya? Jarak jauh?

Itu konyol. Diskusi difokuskan pada penanganan Windows yang memiliki garis miring terbalik sebagai default saat Anda menulis skrip untuk lintas platform. Itu tetap fokus pada topik itu. Anda mencoba membuatnya terdengar seperti tidak fokus sama sekali.

@iSazonov , saya setuju bahwa ada terlalu banyak masalah terbuka; namun, fakta bahwa ada terlalu banyak masalah terbuka tidak berarti kita harus mengabaikan dan menutup pembicaraan tentang masalah baru sebelum waktunya. Kita harus terus mendorong umpan balik dan terbuka untuk diskusi tentang PowerShell dalam masalah terbuka, dan hanya menutupnya setelah benar-benar diselesaikan. Volume masalah terbuka harus ditangani secara berbeda.

Pengguna linux yang setia? Saran yang tidak bisa dipahami.
Anda dapat meyakinkan Microsoft. Minta mereka untuk menggunakan garis miring terbalik sebagai jalur file sistem.

Saya ingin berpadu di sini bahwa ada kasus penggunaan di mana jalur literal dengan garis miring ke depan diperlukan, bahkan di Windows.

Saya baru saja menulis skrip di mana saya menggunakan .net API untuk memanipulasi dan membuat arsip zip. Menambahkan entri ke file zip dengan API ini:

    [System.IO.Compression.ZipFileExtensions]::CreateEntryFromFile(
        $zip, $file, $entry,
        [System.IO.Compression.CompressionLevel]::Optimal
    ) > $null

Dalam kasus khusus ini, $entry adalah jalur di dalam arsip zip. Jika saya hanya melewati jalur windows seperti yang dikembalikan oleh berbagai cmdlet jalur, setiap utilitas zip di planet ini akan memuntahkan peringatan tentang file zip saya yang memiliki garis miring yang salah.

Juga sebagai pengguna dan pengembang linux yang lama, saya suka PowerShell dan saya sangat senang mempelajarinya. Saya telah bersenang-senang bermain dengan inti server windows baru saya melalui ssh ke PowerShell 7 juga, dan saya telah menerbitkan skrip yang bekerja sempurna dengan PowerShell di linux. Saya terkejut seberapa baik itu bekerja. Faktanya, PowerShell akan menjadi pilihan pertama saya untuk beberapa program/skrip yang ingin saya jadikan lintas platform.

Tapi itu masih membuat saya sedih melihat semua penyelesaian tab saya ditulis ulang dengan garis miring terbalik.

Saya menggunakan jalur seperti /users/foo/somefile di windows sepanjang waktu dan itulah yang ingin saya gunakan.

Sebagian besar API windows mendukung garis miring ke depan dengan baik. Saya menyadari ada beberapa pengecualian, dengan utilitas dan mungkin API, yaitu beberapa permintaan cmd.exe, tetapi saya hanya ingin mengatur sesuatu di $profile saya sehingga secara default semua jalur saya memiliki garis miring ke depan, kecuali saya menggunakan garis miring terbalik secara eksplisit.

Ini tidak akan menyinggung pengguna dan pengembang windows yang terbiasa dengan garis miring terbalik karena mereka tidak akan menggunakan pengaturan ini, dan defaultnya akan mati. Tentu saja, mereka mungkin memutuskan untuk menggunakannya juga jika misalnya mereka memutuskan untuk menulis skrip dan modul lintas platform lebih banyak.

Saya ingin pengaturan ini untuk skrip dan modul saya juga, sehingga saya tidak memiliki masalah tak terduga seperti yang saya tunjukkan di atas.

Pengguna @iSazonov dapat menggunakan garis miring yang nyaman bagi mereka terlepas dari platformnya.

Apakah ini berarti saya dapat mengonfigurasi PowerShell untuk menggunakan garis miring karena itu lebih nyaman bagi saya sebagai pengguna? Saya ingin mengubah jalur yang ditampilkan di Prompt serta pelengkapan otomatis tab yang saat ini mengubah garis miring ke depan menjadi garis miring terbalik.

@aaronfranke , tidak, saat ini tidak ada cara untuk mengkonfigurasi PowerShell dengan cara ini; Saya pikir apa yang @iSazonov coba katakan adalah ketika Anda mengetik jalur secara manual, Anda bebas memilih antara \ dan / (dan Anda bahkan dapat mencampurnya dalam satu jalur) .

Mempertimbangkan keserbagunaan, simbol jalur baru harus diaktifkan sebagai ganti / dan Simbol tradisional meningkatkan kesulitan konversi di seluruh platform

Saya pikir apa yang @iSazonov coba katakan adalah bahwa ketika Anda mengetik jalur secara manual, Anda bebas memilih antara dan / (dan Anda bahkan dapat mencampurnya dalam satu jalur).

Ya, Ini adalah desain PowerShell.

Ini bukan penyelesaian masalah yang telah diangkat di sini, seperti penggantian paksa pemisah jalur Anda selama penyelesaian, atau kemampuan untuk mengonfigurasi cmdlet jalur untuk menggunakan pemisah jalur pilihan Anda, jika kami membuka masalah khusus yang terpisah untuk mereka ?

@rkitover Saya bertanya tentang skenario seperti itu bertahun-tahun yang lalu (Anda dapat menemukan masalahnya) tanpa resolusi apa pun. Ini meyakinkan saya bahwa ini adalah perubahan kosmetik, meskipun membutuhkan banyak usaha. Jika Anda siap untuk berinvestasi di bidang ini dan menarik PR, maka masuk akal untuk membuka diskusi baru.

CP/M dan klon menggunakan / untuk opsi, contoh: DIR/P , CMD/CECHO . Ini adalah perintah yang valid. Jika kita mengganti \ dengan / di mana-mana, saya khawatir kesalahpahaman yang buruk bisa terjadi.

1. Tidak ada yang menggunakan CP/M lagi.

2. Menggunakan / untuk kedua opsi dan jalur pada saat yang sama berfungsi dengan baik di Windows dalam pengujian saya.

3. Alat modern menggunakan - sebagai gantinya, termasuk alat PowerShell dan alat Microsoft lainnya seperti .NET. Menggunakan / untuk opsi harus disimpan untuk kompatibilitas mundur, tetapi pengguna tidak akan bingung dengan alat modern.

Juga, saya ingin mencatat bahwa garis miring / adalah nama karakter yang tidak valid dalam nama file Win32:

https://Gist.github.com/doctaphred/d01d05291546186941e1b7ddc02034d3

Inti

Karakter tidak valid untuk nama file Windows

Karakter tidak valid untuk nama file Windows. GitHub Gist: langsung membagikan kode, catatan, dan cuplikan.

Saya hanya ingin menunjukkan bahwa saya mulai menggunakan garis miring hanya dalam skrip lintas platform dll dan mengalami masalah dengan tautan simbolik.

Sebagai contoh, jalankan

new-item -itemtype SymbolicLink -path TestScript8.ps1 -target ./TestScript.ps1

di Windows dan Anda tidak akan bisa membuka TestScript8.ps1 di VS Code di Windows.

@markm77 , Anda telah menemukan _bug_ - dapatkah Anda membuat masalah baru untuknya ? [_update_: lihat #13064]

Bukannya itu adalah argumen yang menentang mekanisme keikutsertaan untuk default ke / , @aaronfranke , tetapi perhatikan bahwa ada beberapa kasus tepi di mana / alih-alih \ masih rusak hal-hal di Windows; misalnya:

PS> cmd /c dir C:/
Invalid switch - ""

Mengutip dua kali jalur hanya membantu dengan jalur _directory_, anehnya - lihat https://stackoverflow.com/a/43297482/45375 , yang juga menunjukkan bahwa pustaka Otomatisasi COM Excel tidak mendukung / .

Stack Overflow

Mengapa PowerShell tidak ingin menyimpan file saya sebagai CSV

$Path = 'D:/ETL_Data/TwitchTVData.xlsx' $csvPath = 'D:/ETL_Data/TwitchTVData2.csv' # Buka dokumen Excel dan tarik lembar kerja 'Sheet1' $Excel = New-Object -Com Excel.Application $Buku kerja...

@markm77 , Anda telah menemukan bug - dapatkah Anda membuat masalah baru untuknya?

Tetapi apakah ini bug PowerShell? PowerShell membuat sym-link yang benar dengan garis miring yang ditentukan sebagaimana diverifikasi dengan memeriksa sym-link menggunakan dir . Tampaknya tautan sym yang dibuat dengan jenis garis miring yang salah kemudian tidak dapat digunakan di aplikasi seperti VS Code. Yang juga bisa dimengerti mungkin.

NB cukup mudah untuk mengatasi masalah ini dengan menjalankan convert-item pada target sym-link yang memiliki manfaat tambahan untuk memastikan sym-link mengarah ke jalur absolut (mungkin sesuai).

NB cukup mudah untuk mengatasi masalah ini dengan menjalankan convert-item pada target sym-link yang memiliki manfaat tambahan untuk memastikan sym-link mengarah ke jalur absolut (mungkin sesuai).

Tidak sesuai, akan pecah saat dipasang ulang

Tidak sesuai, akan pecah saat dipasang ulang

Komentar yang adil, saya tidak me-remount (ini untuk pekerjaan dev lokal) dan saya memiliki skrip untuk pembuatan ulang tautan yang dapat saya jalankan kapan saja. join-path jelas merupakan solusi lain atau bahkan lebih baik lagi adalah opsi new-item untuk memastikan tautan sesuai platform.

Lihat #12797

Tetapi apakah ini bug PowerShell?

Meskipun Anda dapat berargumen bahwa pada _Windows_ ini adalah bug WinAPI, mengingat bahwa \ dan / biasanya didukung secara bergantian, ini jelas merupakan bug pada platform mirip Unix jika Anda melakukan sebaliknya dan meneruskan jalur berbasis \ sebagai jalur -Target - pada platform seperti itu, hanya / yang didukung secara asli (hanya PowerShell yang memungkinkan Anda menggunakan \ sebagai alternatif, yang datang dengan masalahnya sendiri - lihat #9244), dan merupakan tanggung jawab PowerShell untuk menerjemahkan sesuatu seperti .\TestScript.ps1 ke ./TestScript.ps1 saat membuat symlink.

Memperbaiki ini - dengan membuat PowerShell menormalkan jalur untuk menggunakan pemisah _platform-asli_ (utama) - juga akan memperbaiki masalah pada Windows.

@iSazonov , #12797 secara fundamental mengaktifkan dukungan untuk jalur _relative_ sebagai target symlink, tetapi masalah yang dihadapi adalah kurangnya normalisasi pemisah platform-asli, yang membuat symlink yang dihasilkan rusak.

@iSazonov Silakan lihat #13064 untuk apa yang masih rusak pada PowerShell Core 7.1.0-preview.4 (yang harus menyertakan #12797, kan)?

Terima kasih @mklement0 atas apa yang tampak sebagai penyelidikan menyeluruh terhadap perilaku symlink relatif dan peningkatan masalah https://github.com/PowerShell/PowerShell/issues/13064. Saya telah membuat catatan untuk menindaklanjuti lebih lanjut masalah khusus yang saya miliki dan diskusi ini tetapi sebenarnya tampaknya Anda telah membahas semuanya di https://github.com/PowerShell/PowerShell/issues/13064 dan sebenarnya mengajari saya caranya untuk menulis tes PowerShell (Saya baru menggunakan PowerShell).... Cheers!

Saya tidak mengikuti masalah ini dalam setiap detail jadi maafkan saya jika saya melewatkan sesuatu. Masalah awal adalah pemisah jalur standar lintas platform (berpotensi garis miring ke depan). @iSazonov sekarang menutup masalah ini. Bisakah Anda memberikan ikhtisar mengapa menurut Anda ini tidak lagi valid sehingga orang-orang yang berlangganan pada acara penutupan masalah dapat mengikuti?

Itu tidak pernah valid, sesuai https://github.com/PowerShell/PowerShell/issues/10509#issuecomment -644419471 .

Sesuatu seperti apa yang @lzybkr usulkan di atas masih merupakan hal yang sangat masuk akal - dan mungkin mudah - untuk diterapkan; untuk rekap:

Saya pikir akan lebih baik jika penyelesaian jalur menggunakan pemisah jalur yang muncul secara eksplisit dalam teks penyelesaian, dan jika tidak ada, maka default ke pemisah asli platform.

Maka merupakan tanggung jawab pengguna untuk menghindari kasus - langka - edge di mana / masih rusak pada Windows (lihat di atas ).

Ini menyebabkan sakit kepala yang nyata saat menjalankan skrip bash wsl melalui PowerShell. Suka:

bash .\updateTemplate.sh

Ini harus dilengkapi secara otomatis untuk

bash ./updateTemplate.sh

Apakah ada solusi lain untuk masalah ini? khususnya saya akan benar-benar baik-baik saja jika jalur pelengkapan otomatis PS dengan garis miring ke depan hanya pada konteks bash/WSL.

Apakah ada solusi lain untuk masalah ini?

Buat pelengkap khusus untuk bash.

Apakah ada solusi lain untuk masalah ini?

Buat pelengkap khusus untuk bash.

Bagaimana kamu melakukan ini?

Apakah kita tidak mendapatkan diskusi lagi tentang penutupan tidak berdasar dari masalah ini? Ini adalah gangguan besar untuk pekerjaan lintas platform. Setiap kali saya melengkapi jalur secara otomatis yang diumpankan ke alat lintas platform atau secara tidak langsung melalui wsl ke alat Linux, saya harus menggerakkan kursor saya mundur melalui seluruh jalur dan secara individual mengganti setiap garis miring terbalik dengan garis miring. Tidak seorang pun harus bekerja dengan cara ini, dan itu benar-benar membuat Powershell sebagai baris perintah hampir tidak dapat dipertahankan.