Powershell: Tambahkan dukungan untuk folder khusus (folder yang dikenal) melalui penyedia / namespace terpisah

Tampaknya menggunakan awalan untuk folder khusus lebih baik UX daripada parameter. Kita tidak bisa menggunakan ~ , mungkin ~~MyPictures ?

@septianjoko_

Saya tahu bahwa -SpecialFolder (atau -SpecialDirectory , mengingat PowerShell menggunakan istilah _directory_) itu panjang, tetapi alias -sf akan menguranginya.

~~MyPictures , setidaknya secara hipotetis, merupakan perubahan yang merusak, karena tidak ada yang menghentikan Anda untuk membuat folder yang secara harfiah bernama ~~MyPictures .
(Perhatikan bahwa kerangka seperti POSIX mendukung ~<username> sebagai pintasan untuk merujuk ke folder beranda pengguna yang berbeda (tetapi hanya jika digunakan _unquoted_), tetapi ini adalah fitur yang tidak jelas yang menurut saya tidak layak untuk diterapkan di PowerShell. )

Secara umum, arti dari ~ adalah relatif terhadap penyedia yang mendasari _current location_ dan oleh karena itu secara umum tidak cocok untuk merujuk tanpa syarat ke lokasi sistem file.

Solusi yang lebih mirip PowerShell adalah:

• Menerapkan penyedia drive SpecialFolder yang mengekspos, katakanlah, drive sf: ,

• yang kemudian akan memungkinkan Anda menggunakan notasi namespace untuk mengakses itemnya; misalnya,
  Set-Location $sf:MyPictures

Juga, cd ~\pictures lebih sedikit untuk mengetik. Ditto dengan cd ~\desktop . Dengan penyelesaian tab, bahkan ada lebih sedikit untuk mengetik cd ~\de<tab> .

@bayu_joo :

Ya, tetapi (a) sudah berfungsi dan (b) hanya jika lokasi saat ini adalah lokasi sistem file.

Sementara di lokasi filesystem, ~ adalah jalan pintas yang nyaman (sayangnya, tidak sepenuhnya setara secara semantik dengan (tidak dikutip) ~ dalam shell mirip POSIX seperti bash jatuh tempo ke sensitivitas lokasi saat ini).

Selain batasan yang disebutkan, oleh karena itu Anda dapat menganggap ~ sebagai singkatan dari _one_ folder khusus di PowerShell yang sudah tersedia, dan untuk folder khusus lainnya yang _terjadi_ di _subtree_ folder utama, sesuatu seperti ~/Desktop bekerja dengan baik.

Namun, seperti ~ adalah abstraksi yang berguna - ini mungkin merujuk pada, katakanlah, C:\Users\jdoe , /home/jdoe , atau /Users/jdoe , misalnya - memiliki abstraksi untuk folder terkenal lainnya sama-sama berguna, dan di situlah folder khusus masuk.

Misalnya, folder khusus ApplicationData adalah sesuatu seperti C:\Users\jdoe\AppData\Roaming di Windows, dan $env:HOME/.config pada platform mirip Unix.

Bahkan ~ memiliki batasan konseptualnya: seperti yang ditunjukkan @iSazonov di https://github.com/PowerShell/PowerShell/issues/6791#issuecomment -393465147, Anda dapat memikirkan ~ di _Unix_ sesuai dengan ~\Documents di _Windows_, mengingat bahwa Windows tidak menganjurkan membuat konten pengguna secara langsung di folder profil;
Tidak seperti, ~ , folder khusus MyDocuments (alias: Personal ) menyediakan abstraksi ini secara tepat: ia mengembalikan nilai yang setara dengan ~ ( $HOME ) di Unix, dan ~/Documents di Windows.

Singkatan ~ tidak dapat diskalakan dengan baik: sesuatu seperti ~~MyDocuments dan ~MyDocuments , seperti yang dinyatakan, merupakan perubahan besar, tetapi, mungkin yang lebih penting, itu akan bertentangan dengan diri sendiri dalam kasus folder _user-independent_, seperti CommonApplicationData (yaitu C:\ProgramData di Windows, dan /usr/share di Unix).

tetapi (a) sudah berhasil

Ya, saya mempertanyakan nilai fitur yang diusulkan.

folder khusus ApplicationData adalah seperti C: UsersjdoeAppDataRoaming di Windows, dan $ env: HOME / .config pada platform mirip Unix.

Mencoba memetakan lokasi berorientasi Windows ke * nix sepertinya bukan ide yang bagus bagi saya.

~~ MyPictures, setidaknya secara hipotetis, merupakan perubahan besar, karena tidak ada yang menghentikan Anda untuk membuat folder yang secara harfiah bernama ~~ MyPictures.

Kenapa berhenti? Kita bisa menggunakan escaping dan LiteralPath.
Tampaknya di Unix ~ adalah nama yang valid juga. Dan semua opsi lainnya juga.
Saya pikir kita bisa meningkatkan ~ dan menggunakan ~ CommonApplicationData.

Mencoba memetakan lokasi berorientasi Windows ke * nix sepertinya bukan ide yang bagus bagi saya.

Ini telah diterapkan di CoreFX dan PowerShell Core.

Ini telah diterapkan di CoreFX dan PowerShell Core.

Nah, kecuali banyak dari nilai pencacahan itu tidak masuk akal di Linux / macOS. Dengan demikian, sebagian besar dari pencacahan tersebut menghasilkan hasil string kosong:

17:16ms>  $ht = @{}; [Enum]::GetValues('System.Environment+SpecialFolder') | % { $ht[$_] = [Environment]::GetFolderPath($_) }; $ht

Name                           Value
----                           -----
CDBurning
CommonOemLinks
LocalizedResources
Resources
CommonVideos
CommonPictures
CommonMusic
AdminTools
CommonAdminTools
CommonDocuments
CommonTemplates
CommonProgramFilesX86
CommonProgramFiles
ProgramFilesX86
SystemX86
UserProfile                    /home/hillr
MyPictures
ProgramFiles
System
Windows
CommonApplicationData          /usr/share
History
Cookies
InternetCache
LocalApplicationData           /home/hillr/.local/share
PrinterShortcuts
ApplicationData                /home/hillr/.config
CommonDesktopDirectory
CommonStartup
CommonPrograms
CommonStartMenu
Templates
Fonts
NetworkShortcuts
MyComputer
DesktopDirectory
MyVideos
MyMusic
StartMenu
SendTo
Recent
Startup
Favorites
MyDocuments                    /home/hillr
Programs
Desktop

Akibatnya, ini akan menjadi fitur IMO yang berpusat pada Windows.

@bayu_joo :

Ya, saya mempertanyakan nilai fitur yang diusulkan.

Pada catatan meta: Jika menentang sifat lintas platform fitur adalah argumen Anda sejak awal, dapatkah saya meminta Anda untuk memotong "komentar tengah" di masa mendatang? "Juga, cd ~\pictures kurang untuk diketik ..." tidak cukup menyampaikan argumen itu, dan tanggapan saya yang panjang tidak akan diperlukan (meskipun itu mudah-mudahan menarik untuk gambaran yang lebih besar).

Seperti yang tersirat dalam pernyataan @iSazonov, CoreFx melihat nilai dalam fitur tersebut, mengingat bahwa keputusan eksplisit dibuat untuk menyertakannya di platform non-Windows:

Ini berguna untuk alasan yang sama yang selalu berguna, meskipun hanya untuk Windows, bekerja di versi Windows dan variasi konfigurasi: ini menyediakan _ abstraksi yang dapat diandalkan_, mengingat jalur hard-code mungkin gagal.

Dalam dunia _cross-platform_, abstraksi bahkan lebih penting untuk merujuk ke _lokasi yang secara konseptual ekuivalen_ , JIKA padanan tersebut ada, karena penentuan casing khusus dari nilai untuk setiap platform dalam kode lintas platform jelas sangat rumit.

Percakapan terkait adalah perlunya versi abstrak platform dari variabel lingkungan %TEMP% Windows - lihat # 4216
(Sekali lagi, CoreFx telah memimpin jalan ke sana dengan [System.IO.Path]::GetTempPath() . Sebagai tambahan: bisa dibilang, lokasi file-sementara juga harus menjadi folder khusus, yang saat ini tidak.)

Nah, kecuali banyak dari nilai pencacahan itu tidak masuk akal di Linux / macOS.

Benar, banyak folder khusus yang hanya masuk akal di Windows, tetapi, untungnya, CoreFx telah melakukan pekerjaan untuk kami dengan mengidentifikasi folder yang _do_ masuk akal di seluruh platform : mengembalikan string _ kosong_ adalah cara [Environment]::GetFolderPath() untuk memberi tahu kami bahwa lokasi yang setara _tidak_ ada.

Saat membuat kode lintas platform, tidak ada cara lain untuk mengetahui subset mana yang masuk akal.

@bayu_joo

Akibatnya, ini akan menjadi fitur IMO yang berpusat pada Windows.

Memang, dan karena itu belum benar-benar muncul selama lebih dari satu dekade _Windows_ PowerShell (sudah diusulkan tetapi tidak ada banyak minat), saya tidak yakin itu menambah banyak nilai. Sebagian besar folder yang menarik lebih mudah tersedia ~. Tapi saya rasa itu tidak akan menyakitkan.

@bayu_joo

Sementara di lokasi sistem file, ~ adalah jalan pintas yang nyaman (yang, sayangnya, tidak sepenuhnya setara secara semantik dengan (tidak dikutip) ~ di shell mirip POSIX seperti bash karena sensitivitas lokasinya saat ini).

Dalam hal apa itu tidak sepenuhnya setara secara semantik? Apakah maksud Anda fakta bahwa itu membawa Anda ke lokasi rumah pada drive saat ini?

Anda dapat memikirkan ~ di Unix yang sesuai dengan ~ Dokumen di Windows, mengingat bahwa Windows tidak menganjurkan membuat konten pengguna secara langsung di folder profil;

Saat ini, kebanyakan distro Linux dan juga MacOS menggunakan struktur folder yang sama dengan Windows, dengan direktori Dokumen, Gambar, Film, dll. Jadi ~ in * sh dan ~ di PowerShell hampir sama.

@Bayu_joo

Memang, dan karena itu belum benar-benar muncul selama lebih dari satu dekade Windows PowerShell (sudah diusulkan tetapi tidak banyak yang menarik)

Di Windows, Anda biasanya bisa lolos dengan jalur kode keras (semi-).
Di dunia lintas platform, itu bukan lagi pilihan, sehingga abstraksi folder khusus menjadi lebih berharga.

Dalam hal apa itu tidak sepenuhnya setara secara semantik? Apakah maksud Anda fakta bahwa itu membawa Anda ke lokasi rumah pada drive saat ini?

Ya: Jika Anda berasal dari latar belakang Unix dan mengharapkan cd ~\Desktop untuk _always_ membawa Anda ke $HOME\Desktop , Anda akan terkejut:

PS> Set-Location Alias:
PS Alias:/> cd ~\Desktop  # boom
cd : Home location for this provider is not set. To set the home location, call "(get-psprovider 'Alias').Home = 'path'".
...

Saat ini, kebanyakan distro Linux dan juga MacOS menggunakan struktur folder yang sama dengan Windows, dengan direktori Dokumen, Gambar, Film, dll. Jadi ~ in * sh dan ~ di PowerShell hampir sama.

Untungnya, ya (meskipun CoreFx telah memilih untuk mempertimbangkan hanya ~ yang setara dengan Windows ~/Documents melalui [Environment]::GetFolderPath('MyDocuments' , tetapi itu tidak akan mempengaruhi penggunaan eksplisit ~/Documents ).

Namun, seperti yang disiratkan oleh di atas, skrip hanya boleh menggunakan $HOME , bukan ~ , untuk _reliably_ merujuk ke folder utama pengguna.

@septianjoko_

Kenapa berhenti? Kita bisa menggunakan escaping dan LiteralPath.

Tidak seperti di shell seperti POSIX, di mana _shell_ memperluas ~ , dan _hanya jika unquoted_, ~ di PowerShell _is_ jalur literal, dan _ sampai ke penyedia target_ untuk menafsirkannya; pernyataan berikut semuanya setara:

Set-Location ~    # implied -Path
Set-Location '~'  # ditto, with quoting
Set-Location -LiteralPath ~
Set-Location -LiteralPath '~'

Saya pikir ide PSDrive khusus adalah ide yang sangat bagus

@bayu_joo

Ya: Jika Anda berasal dari latar belakang Unix dan mengharapkan cd ~ Desktop selalu membawa Anda ke $ HOMEDesktop, Anda akan terkejut:

Berasal dari latar belakang Unix / POSIX, saya akui bahwa ini adalah keputusan yang tidak membuat saya senang. Kami telah mempertimbangkan untuk mengubahnya beberapa kali tetapi tidak. Saya berharap kami melakukannya untuk 6.0.

Tidak seperti shell seperti POSIX, dimana shell mengembang ~

Benar. Ada perbedaan lapisan dan tanggung jawab. Keuntungannya adalah ini memungkinkan kita untuk melawan hal-hal seperti proses tanpa perlu mengutip.

Di Windows, Anda biasanya bisa lolos dengan jalur kode keras (semi-).
Di dunia lintas platform, itu bukan lagi pilihan, sehingga abstraksi folder khusus menjadi lebih berharga.

Seluruh alasan untuk folder khusus di Windows adalah karena wasn't mungkin memiliki jalur kode keras. Misalnya, dulu disarankan agar Anda memiliki dokumen Anda di drive yang berbeda dari sistem. Hal semacam ini membutuhkan pengalihan. Unix, sebaliknya, cukup konsisten dengan penamaan direktori (/ etc selalu / etc). Dan berbagai distribusi tampaknya telah menetapkan sekumpulan direktori pengguna yang kurang lebih sama.

Untungnya, ya (meskipun CoreFx telah memilih untuk mempertimbangkan ~ setara dengan Windows ~ / Documents via [Environment] :: GetFolderPath ('MyDocuments', tetapi itu tidak akan mempengaruhi penggunaan eksplisit ~ / Documents).

Saya tidak terlalu mengikuti ini. ~ pemrosesan adalah hal PowerShell, bukan hal Windows atau CoreFX. Setidaknya saya tidak tahu mereka melakukan apa pun dengan ~ .

@tokopedia

Kami tidak bisa menggunakan ~, mungkin ~~ MyPictures?

Sebenarnya itu cukup banyak proposal @JamesWTruher dan saya sudah kembali di V1. ~/<directory> akan terkait dengan direktori home tetapi ~documents , ~ApplicationData dll. Akan menjadi folder khusus, Dan sesuatu seperti ~ApplicationData/npm akan menjadi folder khusus jalur relatif -folder. Hal yang menyenangkan dengan pendekatan ini adalah Anda dapat mengizinkan jalan pintas yang ditentukan pengguna, misalnya ~src atau ~test/scripts .

Saat ini, kebanyakan distro Linux dan juga MacOS menggunakan struktur folder yang sama dengan Windows, dengan direktori Dokumen, Gambar, Film, dll. Jadi ~ in * sh dan ~ di PowerShell hampir sama.

Jadi saya berharap CoreFX akan memetakan nama folder khusus lebih luas. Semua pemutar musik yang di-porting dapat menggunakan folder khusus "MyMusic" di platform apa pun.

Pikiran lain tentang ~.

• Saya tidak suka itu bertentangan dengan pengguna Unix ~. Bisakah kita menggunakan prefiks lain?
• Jika kita melihat aplikasi Windows seperti SCCM (manajer konfigurasi pusat sistem) atau GPP (preferensi kebijakan grup), mereka menggunakan format% specialfolder% secara internal.
  CoreFX memiliki Environment.ExpandEnvironmentVariables untuk memperluas variabel lingkungan dan
  Environment.GetFolderPath() untuk memperluas nama folder khusus di jalur.
  Juga di cmd.exe dir %temp% berfungsi tetapi tidak di PowerShell.
  Apakah kami ingin kedua perluasan berfungsi di PowerShell?

@Bayu_joo

Misalnya, dulu disarankan agar Anda memiliki dokumen Anda di drive yang berbeda dari sistem. Hal semacam ini membutuhkan pengalihan.

Pada catatan terkait: Sepertinya yang dilaporkan PowerShell sebagai $HOME adalah %USERPROFILE% , yang _typically_, tetapi belum tentu sama dengan %HOMEDRIVE%%HOMEPATH% ; yang pertama adalah bagian roaming dari profil pengguna dan yang terakhir adalah tempat _files_ pribadi pengguna pergi.

Jika memang berbeda, sesuatu seperti ~/Desktop tidak akan berfungsi sebagaimana mestinya.

Jadi, mengingat bahwa pengalihan (lokasi abstrak yang instansiasi spesifik mesinnya diperoleh secara terprogram) masih merupakan kebutuhan di dunia Windows, itu bahkan tidak membantu bahwa distro Linux memiliki lokasi standar seperti ~/Desktop - untuk operasi yang andal Anda masih membutuhkan pengalihan.

Saya tidak terlalu mengikuti ini. ~ pemrosesan adalah hal PowerShell, bukan hal Windows atau CoreFX. Setidaknya saya tidak menyadari mereka melakukan sesuatu dengan ~

Saya menggunakan ~ hanya sebagai alias singkatan untuk $HOME (Unix) dan %HOMEDRIVE%%HOMEPATH% (Windows) dalam contoh saya (saya akan memanggil keduanya $HOME bawah) .

Saya mencoba menunjukkan bahwa jika Anda meminta .NET API untuk jalur ke dokumen pengguna - [Environment]::GetFolderPath('MyDocuments') :

• Anda mendapatkan $HOME _itself_ di Unix
• Anda mendapatkan $HOME\Documents di Windows

Dengan kata lain: dari perspektif CoreFx, lokasi $HOME/Documents - meskipun _exist_ di semua platform - tidak dianggap _equivalent_ di seluruh platform.

Untuk meringkas:

Hasilnya:

• Bahkan skrip khusus Windows mendapatkan keuntungan dari penggunaan abstraksi, karena sesuatu seperti ~\Desktop atau $HOME\Desktop tidak selalu berfungsi.

• Skrip lintas platform sepenuhnya terbatas pada subset yang relatif kecil dari folder khusus.

• Lebih banyak abstraksi tersedia untuk skrip yang menargetkan Windows + macOS, atau Windows + Linux saja.

Secara khusus, berikut adalah daftar folder khusus yang ditentukan pada platform apa :

• Windows: Karena fitur berasal dari sana, folder khusus _all_ ditentukan.

• Shared - didefinisikan di _all_ platform (catatan: Desktop dan DesktopDir , meskipun secara teknis berbeda, tampaknya merujuk ke lokasi yang sama dalam praktiknya; yang pertama dibedakan dari yang terakhir sebagai "Desktop logis daripada lokasi sistem file fisik "- tidak yakin apa artinya).

  • ApplicationData
  • CommonApplicationData
  • Desktop
  • DesktopDirectory
  • LocalApplicationData
  • MyDocuments
  • MyMusic
  • MyPictures
  • UserProfile

• selain itu, unik untuk macOS (tidak juga di Linux)

  • Favorites
  • Fonts
  • InternetCache
  • ProgramFiles
  • System

• selain itu, unik untuk Linux (tidak juga di macOS)

  • MyVideos
  • Templates

Di atas diperoleh dengan versi modifikasi dari perintah membantu @rkeithhill :

$ht = @{}; [Enum]::GetValues([Environment+SpecialFolder]) | % { $ht[$_] = [Environment]::GetFolderPath($_) }; $ht.getEnumerator() | ? Value | Sort-Object {[string] $_.key}

Sintaks ulang:

Bisakah kita menggunakan prefiks lain?
Dan sesuatu seperti ~ApplicationData/npm akan menjadi jalur relatif folder khusus.

Secara umum, menggunakan simbol khusus (awalan) - meskipun ringkas - adalah rahasia (sesuatu yang Anda harapkan dari Perl, bukan dari PowerShell), meskipun itu dibangun di atas simbol yang terkenal di dunia _Unix_.

• Juga, seperti yang dinyatakan, mengingat arti mapan dari ~ sebagai folder utama _user_, sesuatu seperti ~ProgramFiles - lokasi yang tidak tergantung pengguna - merupakan kontradiksi sendiri.
• (Sintaks ~<username> dalam kerangka seperti bash adalah ekstensi yang lebih natural dari ~ , tetapi tidak banyak digunakan.)

Demikian pula, kita harus menjauh dari %specialfolder% , mengingat itu terlihat seperti variabel lingkungan cmd.exe , sedangkan PowerShell menggunakan $env:<name> untuk memunculkan variabel lingkungan.

Sebaliknya, menggunakan _namespace notation_ masih memungkinkan untuk dibuat ringkas saat menggunakan idiom PowerShell yang telah ditetapkan; misalnya:

Set-Location $sf:Desktop  # tab-completion would work too

Menerapkan _provider_ hanya untuk tujuan ini mungkin tampak berat, tetapi saat ini melakukannya merupakan prasyarat untuk notasi namespace.

Jadi, pertanyaan yang lebih luas adalah: mungkin kita harus mendukung pendefinisian namespace dengan cara yang lebih ringan, tanpa perlu mengimplementasikan penyedia drive yang lengkap?

@ mklement0 Terima kasih! Saya selalu menyukai analisis Anda.

Aku suka gagasan itu. Hanya tanpa $

Set-Location SpecialFolder:Desktop # full name
Set-Location sf:Desktop  # short name

pertanyaan yang lebih luas adalah: mungkin kita harus mendukung penentuan namespace dengan cara yang lebih ringan, tanpa perlu mengimplementasikan penyedia drive lengkap?

Sepertinya saat ini tidak ada - ini memerlukan perubahan antarmuka internal. Kami memiliki permintaan serupa untuk penyedia.
Namun, kami dapat mengimplementasikan drive baru ini bahkan hari ini :-) - kami hanya membutuhkan RFC. Sangat bagus jika Anda melakukannya. Sepertinya itu akan sangat singkat.

Juga saya tidak akan pergi tanpa perhatian pertanyaan saya tentang variabel lingkungan. Mereka sering digunakan di cangkang lain. Kami harus memikirkan cara menggunakannya dengan lebih mudah di PowerShell.

Terima kasih, @iSazonov; Demikian pula, saya menghargai upaya tak kenal lelah Anda dan kontribusi yang tak terhitung jumlahnya.

Setelah dipikir-pikir, Anda benar: menerapkan penyedia drive adalah cara yang harus dilakukan, dan solusi yang tepat adalah membuat _implementing_ satu lagi "ringan", yaitu: lebih mudah: # 5789.

Mengenai bagaimana item drive baru itu harus diakses, izinkan saya mulai dengan variabel lingkungan, karena bagaimana mereka dimunculkan mencontohkan bagaimana menurut saya folder khusus harus dimunculkan juga:

Juga saya tidak akan pergi tanpa perhatian pertanyaan saya tentang variabel lingkungan. Mereka sering digunakan di cangkang lain. Kami harus memikirkan cara menggunakannya dengan lebih mudah di PowerShell.

Saya pikir cara PowerShell untuk mengekspos variabel lingkungan berfungsi dengan baik dan cukup:

• Drive env: menghitung semua variabel lingkungan (misalnya, (Get-Item Env:PATH).Value melaporkan nilai variabel lingkungan PATH )

• Oleh karena itu, fitur notasi ruang nama generik memungkinkan mengakses item ini menggunakan, misalnya, $env:PATH ; dengan kata lain: $<drive-name>:<item-name> adalah yang ringkas (dan mungkin lebih efisien) setara dengan (Get-Item <drive-name>:<item-name>).Value )

Notasi namespace membuat notasi ringkas, namun bersahabat yang mendukung penyelesaian tab dan bahkan embedding langsung dalam string yang dapat diperluas (tanpa perlu menyertakan $(...) ); misalnya:
"PATH: $env:PATH"

Ini adalah konsep yang kuat, dan meskipun penggunaan namespace $env: tersebar luas - karena ini adalah cara termudah untuk mengakses variabel lingkungan - menurut saya tidak banyak orang yang tahu seberapa umum mekanisme yang mendasarinya.

Jika kita menerapkan penyedia drive SpecialFolders dan memunculkan folder khusus melalui drive baru bernama sf: (kita dapat menamainya SpecialFolder: , tetapi perhatikan bahwa tidak ada konsep nama-drive alias, jadi dari apa yang saya pahami, jika kita ingin mendukung sf: dan SpecialFolder: , kita harus mendefinisikan _two_ drive), mengaksesnya melalui notasi namespace terlihat seperti yang saya usulkan:

Set-Location $sf:Desktop 

Itu sebenarnya akan menghilangkan kebutuhan untuk memperpanjang Get-Location , karena Get-Item sf:Desktop Get-Content sf:Desktop sudah cukup - atau hanya $sf:Desktop .

Sebaliknya, sintaks yang Anda usulkan adalah _break_:

Set-Location sf:Desktop   # !! breaks, if sf: is not a file-system provider drive

Ini akan mencoba untuk menavigasi ke sf: drive Desktop _container_, tetapi Desktop bukanlah sebuah wadah: ini adalah _leaf-type item_ yang serupa dengan _files_ di penyedia sistem file. [_update_: lihat [di bawah] (https://github.com/PowerShell/PowerShell/issues/6966#issuecomment-663890154)]

(Demikian pula, Set-Location Env:PATH break, seperti halnya panggilan analog untuk semua penyedia _non-hierarchical_ yang hanya memiliki _satu_ level item tipe daun, yaitu: Alias: , Function: , Variable: - satu-satunya jalur yang dapat Anda tuju pada drive penyedia tersebut adalah lokasi _root_; misalnya, Set-Location Env: .)

Ini mungkin terkait. Saya baru saja menginstal PowerShell 6.1.2 dan ketika saya cd \Users\<user>\Desktop , saya tidak dapat membuat folder menggunakan mkdir test . Saya bisa dengan PowerShell 5.1.17763.124. Ini dengan dan tanpa akses admin.

Kesalahannya adalah:

`` ''
▶ $ kesalahan [0] | fl * -f

writeErrorStream: Benar
PSMessageDetails:
Pengecualian: System.IO.FileNotFoundException: Tidak dapat menemukan file
'C: usersprafulDesktoptest'.
Nama file: 'C: usersprafulDesktoptest'
di System.IO.FileSystem.CreateDirectory (String fullPath)
di System.IO.Directory.CreateDirectory (jalur String)
di Microsoft.PowerShell.Commands.FileSystemProvider.Creat
eDirectory (Jalur string, Boolean streamOutput)
TargetObject: C: usersprafulDesktoptest
CategoryInfo: WriteError: (C: usersprafulDesktoptest: String)
[Item-Baru], FileNotFoundException
FullyQualifiedErrorId: CreateDirectoryIOError, Microsoft.PowerShell.Commands.NewItem
Perintah
Rincian kesalahan :
InvocationInfo: System.Management.Automation.InvocationInfo
ScriptStackTrace: pada,: baris 52
di,: baris 1
PipelineIterationInfo: {0, 1}
`` ''

Membuat direktori di \Users\<user> bekerja. Masalahnya tampaknya ada pada folder khusus (Desktop, Favorit, Dokumen, dll) pada Windows 10 1809.

Apa ada yang berubah ?!

@Praful Silakan buka Masalah baru dengan langkah-langkah repo.

@ mklement0 Apakah diskusi siap untuk ditinjau Komite PowerShell? Bisakah Anda meringkas diskusi?

Terima kasih atas tindak lanjutnya, @iSazonov : Ya, saya pikir sudah siap; untuk meringkas, proposalnya adalah:

Sediakan abstraksi lintas platform yang nyaman untuk folder terkenal dengan cara idiomatik PowerShell dengan menampilkan fungsionalitas [Environment]::GetFolderPath() melalui notasi variabel namespace $sf:<known-folder-name> , di mana sf adalah singkatan dari _special folder_ dan <known-folder-name> adalah Environment.SpecialFolder nilai enum - misalnya, $sf:Desktop akan setara dengan [environment]::GetFolderPath('Desktop')

Catatan: Tidak semua folder terkenal ada di semua platform - lihat bagian bawah komentar ini untuk detailnya; jika tidak, [Environment]::GetFolderPath() mengembalikan _ string kosong_ (mis., [environment]::GetFolderPath('CDBurning') di macOS); kita bisa meniru praktik itu.

Untuk itu:

• Menerapkan penyedia non-hierarki, baca-saja yang mengimplementasikan antarmuka IContentCmdletProvider dan yang itemnya dinamai untuk nilai enumerasi Environment.SpecialFolder dan yang isinya adalah nilai untuk meneruskan nama mereka ke [Environment]::GetFolderPath()

• Tentukan drive bernama sf untuk penyedia itu.

Sebagai perpanjangan opsional untuk proposal di atas:

• Terima nilai enum tambahan bernama, katakanlah, Temp , untuk mengembalikan jalur khusus platform ke folder untuk file sementara yang memunculkan nilai [System.IO.Path]::GetTempPath() , PowerShell saat ini tidak memiliki analog - lihat # 4216 ; dukungan untuk $sf:Temp akan menyelesaikannya.

@ SteveL-MSFT Masalah ini siap untuk ditinjau oleh komite PowerShell.

@ PowerShell / PowerShell-committee mulai membahas hal ini tetapi tidak mencapai kesimpulan. Satu proposal yang muncul adalah folder di bawah env: dan bukan PSDrive baru. Jadi akan terlihat seperti env:/SpecialFolder/Fonts , misalnya. Meskipun SpecialFolders bukanlah variabel lingkungan, mereka adalah folder yang merupakan bagian dari lingkungan pengguna, jadi secara konseptual, ini berfungsi.

Saya tidak akan merekomendasikan itu. Membutuhkan pemisah garis miring untuk mengaksesnya berarti mengaksesnya seolah-olah variabel (seperti yang Anda bisa dengan $ env: TEMP) menjadi tidak praktis. Tidak semua orang mengetahui sintaks yang diperkuat untuk variabel, lagipula, ini sedikit hal khusus.

Tampaknya maksud di sini adalah untuk mempermudah mengakses folder-folder ini, dan menurut saya menguburnya dalam subpohon khusus Env: tidak masuk akal untuk mencapai tujuan itu. Segala sesuatu yang lain di sana adalah larik string satu dimensi datar satu tingkat, secara efektif ... Kecuali ada rencana lebih lanjut untuk mengabstraksi dorongan untuk meningkatkan kegunaan dan membuatnya lebih kuat secara keseluruhan, saya sangat meragukan bahwa membuat kasus khusus di sini akan membantu apa pun.

SpecialFolder-s masih bukan variabel lingkungan.

@ vexx32 mengulangi beberapa keprihatinan yang saya alami minggu lalu, sebenarnya tentang bagaimana orang telah secara mental memetakan $env di kepala mereka. Bagi saya (dan saya mengharapkan sebagian besar komunitas juga) $env dan penyedia Lingkungan == "variabel lingkungan". Menurut @JamesWTruher , $env seharusnya berisi informasi berguna tentang lingkungan, lebih mirip dengan [System.Environment] yang kemudian akan menyertakan folder khusus.

Saya berpendapat bahwa maksud aslinya mungkin tidak jelas bagi pengguna dan akan masuk akal untuk membedakan dari $env dalam beberapa cara, dan lebih menyukai sesuatu seperti $sf , tetapi itu berarti kami membutuhkan PSDrive, atau itu akan menjadi variabel otomatis. Seperti yang dikatakan @ mklement0 di atas, kami juga merasa bahwa PSDrive akan menjadi sedikit berat, dan sangat aneh bagi saya karena ini bukan item yang dapat diatur. Anda baru saja mengakses beberapa nilai hanya-baca dari sistem.

Jika ini adalah variabel otomatis, maka kita harus membuat kasus khusus sebagai variabel yang mem-parsing :foo . Dari perspektif "Saya bisa melihat apa yang terjadi di balik terpal", ini juga miring. Saya tahu kami memiliki banyak keajaiban di PowerShell, tetapi kami melakukan yang terbaik untuk tidak menambahkan lebih banyak (isyarat orang-orang memanggil saya karena menginginkan keajaiban di PSModulePath RFC :))

Jadi itulah mengapa kami mendarat di tempat di mana kami ingin bergerak menuju tujuan awal: untuk memindahkan lebih banyak informasi tentang lingkungan ke penyedia Lingkungan. Di masa mendatang, kami menginginkan lebih banyak lagi di luar folder khusus, dan masuk akal untuk menetapkan preseden untuk itu sekarang, jadi kami tidak memperdebatkan lebih banyak penyedia hanya baca di masa mendatang.

Selain itu, saya berpendapat bahwa fitur ini jauh lebih abstraksi lintas platform daripada tentang kemudahan mengetik. Ada banyak cara untuk membuat alias folder yang Anda pedulikan untuk disingkat untuk sesi interaktif Anda, tetapi ini lebih tentang menyediakan cara bagi pengguna PS untuk secara asli mengabstraksi folder khusus ini (apakah itu lintas platform yang kebetulan memiliki nilai yang ditentukan di Linux, serta untuk mengurangi lokasi folder yang berpotensi aneh dalam lingkungan Windows murni).

Karena penasaran, adakah alasan mengapa tidak ada yang mengumpulkan Get-SpecialFolder cmdlet? Apakah ada beberapa masalah parse vs. runtime yang muncul jika kita mengikuti rute itu? (Di mana setiap orang bisa membuat alias menjadi gsf atau sesuatu sehingga misalnya (gsf TEMP) berfungsi.)

Hm. Sebuah cmdlet memiliki overhead sedikit lebih dari penyedia atau semacamnya, tetapi selain itu saya tidak melihat ada yang salah dengan itu.

Saya rasa saya bisa memahami perspektif itu dengan Lingkungan PSProvider. Hal terbesar saat ini adalah bahwa saat ini tampaknya tidak mendukung apa pun seperti node kontainer - mencoba membuat Env:\MyThing\Var saat ini (dari memori, setidaknya) hanya membuat satu item bernama MyThing\Var , bukan?

Saya tidak ragu untuk _mengubah_ itu dan membuatnya berhasil. Akses mudah ke folder khusus akan menyenangkan! 😄

Bagi saya (dan saya mengharapkan sebagian besar komunitas juga) $ env dan penyedia Lingkungan == "variabel lingkungan".

Bagaimana mengatasi ini? Docs mengatakan

Provides access to the Windows environment variables.

Dan kami memiliki konflik - semua variabel env ada di root namespace meskipun saya harapkan:

$env:/specialfolders/
$env:/variables/system/
$env:/variables/user/
$env:/computerinfo/
$env:/osinfo/

ini terlihat seperti / proc di Linux.

@ PowerShell / powershell-committee telah mengulas ini, kami juga akan setuju dengan cmdlet seharga Get-SpecialFolder

@ PowerShell / PowerShell-committee meninjau ini, kami juga akan setuju dengan cmdlet untuk Get-SpecialFolder

IMO pendekatan penyedia (yaitu sf:MyPictures ) akan membuat mengetik lebih sedikit.

Ini akan mencoba untuk menavigasi ke sf: drive Desktop _container_, tetapi Desktop bukanlah sebuah wadah: ini adalah _leaf-type item_ yang serupa dengan _files_ dalam penyedia sistem file.

TEMP: adalah kontainer sekarang, mengapa sf:Desktop bisa?

Saya mengutarakannya dengan buruk:

Idenya adalah untuk $sf:Desktop (yang secara implisit setara dengan Get-Content sf:Desktop - bukan Get-Item sf:Desktop ) untuk langsung mengembalikan jalur _native string_ yang mewakili folder Desktop khusus platform, sehingga Anda dapat menggunakannya _directly_ dalam argumen; misal, [IO.File]::CreateText("$sf:Desktop/foo.txt")

Perilaku ini adalah utilitas utama sintaks $sf:Desktop , mengingat bahwa string jalur penyedia seperti sf:Desktop _dengan sendirinya_ hanya berarti bagi cmdlet_ penyedia _PowerShell (tidak seperti jalur sistem file asli seperti C:\Users\Desktop ).

Jadi pemikiran saya adalah bahwa item drive itu sendiri tidak perlu mewakili item _directory_ (container), dan satu-satunya kebutuhan praktis untuk secara eksplisit memanggil cmdlet penyedia adalah untuk _discovery_: misalnya, Get-ChildItem sf: atau Get-Item sf:*music*

Saya kira kita bisa melakukan _both_, dan juga memperlakukan drive sf: seperti drive _file-system_ berbasis PS-drive lainnya, tetapi ada masalah konseptual:

• Lokasi sistem file apa yang seharusnya diwakili oleh sf:/ - root dari semua folder khusus? Tidak ada kandidat alami, namun kami tidak ingin melarang Set-Location sf:/ sama sekali, karena ini berfungsi dengan penyedia lain (mis., Set-Location alias:/ berfungsi dengan baik); jika lokasi sf:/ tidak mewakili item sistem file yang sebenarnya - sama seperti alias:/ tidak - masalah tidak muncul.

Selain itu, $PWD kemudian akan melaporkan sf:Desktop daripada C:\Users\jdoe\Desktop , misalnya - seperti pada drive PS kustom.

Lokasi sistem file apa yang diwakili oleh My Computer ? Anda dapat menjelajahinya, Anda dapat menautkannya tetapi Anda tidak dapat meneruskannya ke aplikasi yang mengharapkan direktori. Ini adalah situasi yang sama.

Bukan, karena My Computer ( This PC ) adalah konsep namespace shell _GUI_ Windows, dan lokasi abstraknya tidak dapat langsung digunakan di PowerShell, jadi _ masalah saat ini tidak ada_ - kami akan memperkenalkannya ke PowerShell.

(Jika Anda mencoba meluncurkan konsol PowerShell dari File Explorer dari lokasi abstrak seperti This PC , Anda akan mendapatkan set-location : Cannot find path '::{20D04FE0-3AEA-1069-A2D8-08002B30309D}' because it does not exist. , dan, demikian pula, Anda tidak dapat meminta anak-anaknya dengan Get-ChildItem .)

Yang mengatakan, saya akan baik-baik saja dengan, katakanlah, memetakan lokasi sf:/ ke root drive sistem ( / di Unix, dan biasanya C:\ di Windows).

Sekali lagi: Yang penting pada akhirnya adalah bahwa $sf:Desktop secara langsung meluas ke jalur sistem file asli khusus platform yang mendasari lokasi abstrak.

Sesuai dengan penyedia yang ada, akan sangat masuk akal jika SF: itu sendiri dipetakan ke lokasi abstrak dari mana Anda dapat memanggil Get-ChildItem dan mendapatkan daftar folder khusus dan lokasinya:

PS> Get-ChildItem sf:

Name          Location
----          --------
Desktop       C:\Users\currentUser\Desktop
My Documents  C:\Users\currentUser\My Documents
( ... ) 

[_Update_: Lihat [kesimpulan di bawah] (https://github.com/PowerShell/PowerShell/issues/6966#issuecomment-663910975)]

Ya, @ vexx32 , tetapi kami akan mendapatkan perilaku tersebut meskipun item itu sendiri tidak langsung dipetakan ke lokasi sistem file; seperti yang saya katakan di atas:

item drive itu sendiri tidak perlu mewakili item direktori (wadah), dan satu-satunya kebutuhan praktis untuk secara eksplisit memanggil cmdlet penyedia adalah untuk _discovery_: misalnya, Get-ChildItem sf: atau Get-Item sf:*music*

Ini akan bekerja seperti Get-ChildItem alias:/ , untuk drive alias: , yang juga _not_ memetakan ke lokasi sistem file.

Untuk meringkas:

• Yang penting adalah bahwa notasi variabel namespace - misalnya, $sf:Desktop - secara langsung diperluas ke jalur sistem file asli khusus platform yang mendasari lokasi abstrak.

• Saya pribadi baik-baik saja dengan _also_ membuat drive dapat dinavigasi sebagai penyedia _file-system_ khusus (daripada penyedia yang mengembalikan _path strings_), tetapi saya pikir itu jauh kurang penting:

  • Jika kita _tidak_ membuat sf: sebagai penyedia sistem file khusus, tidak banyak yang hilang: alih-alih Set-Location sf:Desktop Anda kemudian harus menggunakan Set-Location $sf:Desktop (analoginya dengan Get-Item dan Get-ChildItem , jika Anda ingin [System.IO.DirectoryInfo] output), yang menurut saya tidak merepotkan - meskipun mungkin ada kebingungan.

  • Jika kita _melakukannya:

    • Kita perlu memutuskan bagaimana menangani Set-Location sf:/ , yaitu menavigasi ke _root location_ drive, yang saat ini didukung oleh semua penyedia.
    • Salah satu: Cegah menavigasi langsung ke sf:/ , dengan pesan kesalahan yang berarti.
    • Atau: Petakan sf:/ ke lokasi sistem file yang sangat sewenang-wenang, seperti root drive sistem.
    • Apa pun itu, kita perlu berhati-hati bahwa setelah, katakanlah, Set-Location sf:Desktop , $PWD akan dirangkai sebagai 'sf:/Desktop' , yang tidak dapat Anda gunakan secara langsung (untuk membuat jalur dengan) dalam panggilan yang mengharapkan jalur sistem file asli. (Ini berlaku untuk drive PS sistem file _custom_ sama-sama, tetapi membuatnya adalah tindakan yang disengaja, sedangkan dalam kasus ini pengguna mungkin tidak mengharapkan perilaku ini; $PWD.ProviderPath adalah solusinya)

@ mklement0 Saya yakin dia baru saja menjawab pertanyaan Anda tentang:

• Lokasi sistem file apa yang harus diwakili oleh sf:/ - root dari semua folder khusus? Tidak ada kandidat alami, namun kami tidak ingin melarang Set-Location sf:/ sama sekali, karena ini berfungsi dengan penyedia lain (mis., Set-Location alias:/ berfungsi dengan baik); jika lokasi sf:/ tidak mewakili item sistem file yang sebenarnya - sama seperti alias:/ tidak - masalah tidak muncul.

dengan "tidak, ini seperti alias:/ ".

Saya juga setuju dengan Anda bahwa membuat konten daun menjadi jalur sebagai string adalah satu-satunya cara untuk menerapkannya sebagai penyedia. Ini akan menjadi aneh meskipun Get-ChildItem sf:Desktop tidak akan bekerja seperti yang diharapkan orang. Saya tahu itu tidak dapat dilakukan dengan cara kerja penyedia saat ini, tetapi mungkin masih terlalu membingungkan.

Terima kasih, @SeeminglyScience , tetapi saya mencoba menunjukkan bahwa hanya jika Anda memahami penyedia yang mendasari sf drive sebagai penyedia _file-system_, Anda harus menyelesaikan masalah tentang lokasi sistem file sf:/ dipetakan ke. Jadi, _if_ kami ingin Get-ChildItem sf:Desktop berfungsi - untuk menghindari kebingungan - kami memang perlu mengimplementasikan penyedia sebagai penyedia sistem file - dan kemudian kami perlu menyelesaikan masalah itu.

Saya benar-benar tidak berpikir Anda bisa dengan cara yang tidak menyebabkan lebih banyak kebingungan. Kecuali Anda hanya kasus khusus semua resolusi jalur mulai dari sf di FileSystemProvider itu sendiri.

Hambatan terbesar dalam implementasi penyedia mana pun yang "agak seperti penyedia X tetapi dengan satu perbedaan ini" adalah Anda tidak dapat melakukan operasi lintas penyedia. Jadi Copy-Item sf:\Desktop C:\temp sudah tertanam untuk dilempar. Juga bagaimana transisi resolusi jalur antara penyedia seperti gi sf:\Desktop\Chrome.lnk . API penyedia tidak dibuat untuk menangani semua itu.

Mohon maaf jika itu semua sudah disebutkan ITT.

Mohon maaf jika itu semua sudah disebutkan ITT.

Saya kira tidak memiliki, @SeeminglyScience , jadi terima kasih telah mengklarifikasi.

Jadi sepertinya kesimpulannya adalah:

• Penyedia yang mendasari drive sf diusulkan saat ini tidak dapat menjadi penyedia sistem file kasing khusus, jadi saat ini kami tidak dapat mendukung panggilan seperti Set-Location sf:Desktop atau Get-Item sf:Desktop ([_update_: while mengharapkan instance [System.IO.DirectoryInfo] sebagai keluaran), meskipun pengguna mungkin mengharapkannya.

• Sebagai penyedia yang itemnya hanya mewakili _path strings_, notasi variabel namespace (misalnya, $sf:Desktop ) berfungsi sebagaimana mestinya - yang penting - dan masih mendukung penemuan melalui Get-ChildItem / Get-Item .
  Set-Location sf:/ - jika tidak perlu memetakan ke lokasi sistem file - maka tidak ada masalah konseptual.

• Penyedia yang mendasari drive sf diusulkan saat ini tidak dapat menjadi penyedia sistem file kasing khusus, jadi saat ini kami tidak dapat mendukung panggilan seperti Set-Location sf:Desktop atau Get-Item sf:Desktop , meskipun pengguna mungkin mengharapkannya.

Mungkin menjelaskan bahwa Get-Item akan berfungsi, hanya saja tidak mengembalikan objek DirectoryInfo .

Menarik, kami berharap bahwa sf: Desktop mengembalikan nilai tetapi alias:% tidak mengembalikan ForEach-Object . Sepertinya masalah mendasar.

@iSazonov ${alias:%} menghasilkan ${alias:%} ForEach-Object

Tapi kami menginginkan Set-Location $ sf: Desktop, bukan Set-Location $ {sf: Desktop}

$sf:Desktop akan bekerja dengan baik, tanda kurung kurawal karena % tidak diperbolehkan dalam nama variabel.

>alias:gcm
alias:gcm: The term 'alias:gcm' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Itu tidak diperluas ke Get-Command.

alias:gcm adalah kata bareword, tidak ada yang perlu dikembangkan di sini.

@iSazonov , yang diharapkan, karena alias:gcm bukanlah jalur _file-system_ yang memungkinkan _direct execution_. Hanya alias _provider_ yang memahami jalur ini, jadi Anda harus menggunakan Get-Item alias:gcm (atau Get-Content alias:gcm untuk mendapatkan _definition_ dari alias tersebut, yaitu _string_ 'Get-Command' ).

Untuk mengeksekusi alias dengan jalur penyedia PS-nya (yang jelas merupakan cara memutar yang tidak perlu untuk melakukannya), Anda harus melakukan ini (di mana $alias:gcm setara dengan Get-Content alias:gcm ):

& $alias:gcm

Jika kami mengizinkan eksekusi variabel secara langsung, kami tidak memerlukan file sementara. Namun, variabel seperti itu tetap harus diberi nama *.PS1 . alias:gcm tidak memiliki ekstensi ini, jadi ekstensi ini dapat diperlakukan sebagai skrip.

seperti yang diharapkan, karena alias: gcm bukanlah jalur sistem file

Apa yang kita inginkan - sf: Desktop atau $ sf: Desktop di Set-Location?

Apa yang kita inginkan - sf: Desktop atau $ sf: Desktop di Set-Location?

Satu-satunya cara yang dapat digunakan dengan cara kerja penyedia saat ini adalah $sf:Desktop .

Meskipun saya ingin menyatakan lagi bahwa menurut saya desain ini terlalu membingungkan untuk orang yang tidak tahu mengapa harus seperti itu. Secara pribadi saya pikir ini harus menunggu sampai operasi resolusi / salin lintas penyedia jalan bekerja.

@Tokopedia

Saya berpotensi menimbulkan kebingungan, tetapi tidak ada yang tahu apakah dan kapan resolusi / operasi penyalinan lintas penyedia akan diterapkan (atau adakah rencana khusus?), Jadi saya rasa kita tidak harus menunggu untuk itu.

Saya melihat utilitas utama dari fitur yang diusulkan dalam _mengomposisikan string jalur melalui interpolasi string / penggabungan_, di mana $sf:Desktop adalah formulir yang diperlukan (misalnya, "$sf:Desktop/subdir" (namun, dengan Join-Path the kebingungan bisa muncul kembali).

Jika kita mengimplementasikan penyedia sekarang dan membuat itemnya _containers_ dengan tipe [System.IO.DirectoryInfo] (dan item _content_ properti .FullName ), maka kita bisa membayangkan nanti transisi ke penyedia sistem file khusus yang terintegrasi penuh - atau apakah saya melewatkan sesuatu?

Kalau dipikir-pikir: Apakah itu saja memungkinkan Set-Location sf:Desktop , mengingat tidak ada operasi _cross_-provider yang terjadi? sebagai gantinya, Anda akan langsung mengubah ke _native file-system path_ yang mendasari item - tapi itu lebih disukai.

[_Update_: Lihat [di bawah] (https://github.com/PowerShell/PowerShell/issues/6966#issuecomment-664603897).]

@ yuliarrrr

Jika kita mengizinkan eksekusi variabel secara langsung

Tidak ada _variable_ di sini (yang _value_-nya dapat Anda panggil dengan & ), hanya _literal path_ yang merujuk ke item yang diekspos oleh penyedia Alias (melalui satu-satunya alias: mendorong).

@tokopedia

PowerShell _conceptually dapat_ - tetapi saat ini tidak - menerima path alias:gcm sebagai _command_ untuk dieksekusi, meskipun System.Management.Automation.AliasInfo instance yang dirujuk path adalah perintah (diturunkan dari System.Management.Automation.CommandInfo ). Mengingat bahwa hanya gcm cukup untuk pemanggilan, bagaimanapun, saya tidak berpikir itu kekurangan dalam praktiknya.
Karena penasaran, @SeeminglyScience : apakah masalah ini dapat

Sebaliknya, untuk jalur seperti sf:Desktop untuk menjadi warga sistem file PS kelas satu, di samping drive sistem file PS kustom, kita memerlukan _penyedia sistem file khusus_, yang mana
menurut analisis @SeeminglyScience , masalah yang tidak dapat diselesaikan dengan cara kerja penyedia saat ini.

tetapi tidak ada yang tahu apakah dan kapan operasi resolusi / penyalinan jalur penyedia akan diterapkan

Ya saya tahu, masih. Rute yang berbeda harus ditempuh segera.

Jika kita mengimplementasikan penyedia sekarang dan membuat itemnya _containers_ dengan tipe [System.IO.DirectoryInfo] (dan item _content_ properti .FullName ), maka kita bisa membayangkan nanti transisi ke penyedia sistem file khusus yang terintegrasi penuh - atau apakah saya melewatkan sesuatu?

Saya pikir ini adalah tantangan pemahaman yang lebih besar. Objek Get-Item adalah DirectoryInfo , tapi ini daun, dan isinya adalah path. Kemudian nanti kita akan membuat mereka tidak lagi menjadi daun dan memberikan Get-Content ? Bahkan jika itu intuitif, itu membuat lebih sulit bagi pengguna untuk menentukan mengapa gci sf:/Desktop atau gi sf:/Desktop/pwsh.lnk tidak berfungsi.

Kalau dipikir-pikir: Apakah itu saja akan mengaktifkan Set-Location sf:Desktop , mengingat tidak ada operasi _cross_-provider yang terjadi? Namun, Anda tidak akan benar-benar mengubah ke lokasi _pada drive sf: _; sebagai gantinya, Anda akan langsung mengubah ke _native file-system path_ yang mendasari item - tapi itu lebih disukai.

Nah, Anda tidak dapat mengatur lokasi Anda ke daun.

PowerShell _conceptually dapat_ - tetapi saat ini tidak - menerima path alias:gcm sebagai _command_ untuk dieksekusi, meskipun System.Management.Automation.AliasInfo instance yang dirujuk path adalah perintah (diturunkan dari System.Management.Automation.CommandInfo ). Mengingat bahwa hanya gcm cukup untuk pemanggilan, bagaimanapun, saya tidak berpikir itu kekurangan dalam praktiknya.
Karena penasaran, @SeeminglyScience : apakah masalah ini dapat

Baik & (gi alias:gcm) bekerja. Saya membayangkan versi yang sangat dasar mungkin dapat dihubungkan melalui ItemCmdletProvider.InvokeDefaultAction jika perubahan yang melanggar diterima. Tetapi eksekusi dengan cara yang sama bekerja untuk penyedia sistem file bisa menjadi masalah besar.

Terima kasih, @SeeminglyScience.

Objek Get-Item adalah DirectoryInfo, tetapi ini adalah daun

Usulannya adalah untuk membuatnya menjadi _container_, tapi, ya, mengizinkan Get-Content untuk melaporkan _path_ penampung akan menjadi anomali (sesuatu seperti Get-Content $HOME saat ini gagal, seperti halnya ${C:\Windows} , dengan Unable to get content because it is a directory: )

Namun, sebaliknya itu berarti bahwa jika kita menunggu sampai kita dapat membuat penyedia drive sf: menjadi penyedia sistem file khusus dan lengkap, itu adalah $sf:Desktop yang tidak akan berfungsi - yang menghilangkan apa yang saya anggap sebagai kasus penggunaan utama: Saya ingin dapat menggunakan $sf:Desktop/file.txt , dan tidak dipaksa untuk menggunakan "$(Get-Item sf:Desktop)/file.txt" atau (Get-Item sf:Desktop/file.txt).FullName - yang rumit dan tidak efisien .

Jadi, bagi saya solusi pragmatisnya adalah: terapkan penyedia yang itemnya adalah _leaf_ item yang mewakili _path strings_ - dan jelaskan dalam dokumentasi bahwa jalur berbasis sf: tidak dapat berfungsi secara langsung sebagai item sistem file.

Baik & (gi alias:gcm) bekerja

Tentu, dan begitu juga & $alias:gcm (meskipun _string_ dikembalikan dalam kasus itu), tetapi pertanyaannya adalah apakah jalan memutar melalui Get-Item / notasi variabel namespace dapat dihindari dalam kasus ini.

Pertanyaannya sebagian besar bersifat akademis: mengingat manfaat yang dapat diabaikan dari mengaktifkan ini dan potensi jebakan, saya setuju bahwa itu tidak layak ditangani.

Usulannya adalah untuk membuatnya menjadi _container_, tapi, ya, mengizinkan Get-Content untuk melaporkan _path_ penampung akan menjadi anomali (sesuatu seperti Get-Content $HOME saat ini gagal, seperti halnya ${C:\Windows} , dengan Unable to get content because it is a directory: )

Itu lagi-lagi cukup membingungkan imo. Sebagai tambahan, menurut saya bukan ide yang baik untuk mengizinkan wadah bekerja dengan Get-Content hanya untuk solusi ini.

Namun, sebaliknya itu berarti bahwa jika kita menunggu sampai kita dapat membuat penyedia drive sf: menjadi penyedia sistem file khusus dan lengkap, itu adalah $sf:Desktop yang tidak akan berfungsi - yang menghilangkan apa yang saya anggap sebagai kasus penggunaan utama: Saya ingin dapat menggunakan $sf:Desktop/file.txt

Ya, saya benar-benar memahami kasus penggunaan. Ini masih akan membingungkan orang-orang.

dan tidak dipaksa untuk menggunakan "$(Get-Item sf:Desktop)/file.txt" atau (Get-Item sf:Desktop/file.txt).FullName - yang tidak praktis dan tidak efisien.

Cara yang sama Anda menyelesaikan jalur sistem file. Juga Resolve-Path .

Jadi, bagi saya solusi pragmatisnya adalah: terapkan penyedia yang itemnya adalah _leaf_ item yang mewakili _path strings_ - dan jelaskan dalam dokumentasi bahwa jalur berbasis sf: tidak dapat berfungsi secara langsung sebagai item sistem file.

Jika itu harus ditambahkan sebagai penyedia itu sendiri, itu akan menjadi satu-satunya cara yang dapat diterapkan saat ini. Saya pikir tidak seharusnya begitu, itu akan terlalu sulit untuk dipahami.

Sejujurnya saya lebih suka melihatnya sebagai casing khusus resolusi jalur FileSystemProvider . Saya tidak begitu yakin apakah itu sepadan dengan kerumitan ekstra, tetapi setidaknya itu akan sangat mudah dimengerti.

Tentu, dan begitu juga & $alias:gcm (meskipun _string_ dikembalikan dalam kasus itu), tetapi pertanyaannya adalah apakah jalan memutar melalui Get-Item / notasi variabel namespace dapat dihindari dalam kasus ini.

Ya saya mengerti, sisa kalimatnya adalah jawaban langsung.

Menurut saya bukan ide yang baik untuk mengizinkan wadah untuk bekerja dengan Get-Content hanya untuk solusi ini.

Sepakat.

Cara yang sama Anda menyelesaikan jalur sistem file. Juga Putuskan-Jalan

Ya, tapi itu merepotkan untuk kasus penggunaan ini.

Jika itu harus ditambahkan sebagai penyedia sendiri, itu akan menjadi satu-satunya cara yang dapat diterapkan saat ini. Saya pikir tidak seharusnya begitu, itu akan terlalu sulit untuk dipahami.

Jika penggunaan utama adalah $sf:Desktop dalam string jalur, saya tidak berpikir orang akan berpikir dua kali tentang hal itu, seperti mereka tidak berpikir tentang $env:HOME didukung oleh operasi penyedia yang merupakan setara dengan Get-Content Env:HOME .
Dengan pelengkapan tab yang tepat, Anda mungkin tidak perlu menyentuh cmdlet penyedia, dan jika Anda menganggap $sf:Desktop hanya sebagai variabel khusus (nilai), Set-Content $sf:Desktop juga bukan peregangan.

Ya, tapi itu merepotkan untuk kasus penggunaan ini.

Bisakah Anda menjelaskannya? Anda hanya perlu melakukan ini jika Anda melewati jalur ke sesuatu yang tidak memahami PSPath. Jika tidak, itu akan bekerja mirip dengan PSDrive.

Jika penggunaan utama adalah $sf:Desktop dalam string jalur, saya tidak berpikir orang akan berpikir dua kali tentang hal itu, seperti mereka tidak berpikir tentang $env:HOME didukung oleh operasi penyedia yang merupakan setara dengan Get-Content Env:HOME .

Variabel lingkungan bukan hanya jalur, pengguna sudah menganggapnya seperti variabel.

Bisakah Anda menjelaskannya?

Saya ingin dapat menggunakan $sf:Desktop/file.txt , yang tidak dapat saya lakukan jika sf:Desktop adalah item kontainer (direktori).

Variabel lingkungan bukan hanya jalur, pengguna sudah menganggapnya seperti variabel.

Itulah maksud saya: pengguna dapat dan harus menganggap $sf:Desktop sebagai variabel (khusus) yang berisi string jalur.
Mendasari ini dengan penyedia hanyalah persyaratan teknis untuk mengaktifkan sintaks ini.

Saya ingin dapat menggunakan $sf:Desktop/file.txt , yang tidak dapat saya lakukan jika sf:Desktop adalah item kontainer (direktori).

Benar saya mengerti, tapi mengapa Anda menginginkannya daripada mengerjakannya menjadi resolusi jalur yang sebenarnya.

Mengapa Anda perlu melakukan:

Copy-Item $sf:Desktop/pwsh.lnk ./pwsh.lnk

Dari pada

Copy-Item sf:/Desktop/pwsh.lnk ./pwsh.lnk

Itulah maksud saya: pengguna dapat dan harus menganggap $sf:Desktop sebagai variabel (khusus) yang berisi string jalur.
Mendasari ini dengan penyedia hanyalah persyaratan teknis untuk mengaktifkan sintaks ini.

Saya mengerti bagaimana Anda ingin itu dilihat, tapi saya pikir itu menantang. Memperkenalkan penyedia yang kontennya berupa jalur sistem file sebagai string yang kemudian Anda teruskan ke penyedia lain untuk diselesaikan ke sebuah item pada dasarnya sulit untuk dipahami.

Saya mengerti bagaimana Anda _ ingin_ video itu dilihat

Ini lebih dari itu: Saya mengusulkan agar _ secara aktif dibingkai dengan cara ini_: untuk mengurangi penekanan pada aspek penyedia _ sebagai detail implementasi_, yang menghindari masalah konseptual. Sebagai gantinya, kita harus membingkai $sf:* sebagai _special variable_ yang mengembalikan _path strings_.

Dalam nada itu:

Copy-Item sf:/Desktop/pwsh.lnk ./pwsh.lnk

Saya tidak tahu apa sf:/Desktop itu (Saya bermain bodoh untuk membuat satu poin) - yang saya tahu adalah bahwa $sf:Desktop mengembalikan Desktop _path string_ yang sesuai dengan platform yang dapat saya gunakan sebagai bagian dari string jalur yang lebih besar - seperti saya akan menggunakan $env: variabel notasi; misalnya:

Copy-Item $env:ProgramFiles/foo/bar.exe ./bar.exe

Jika sf: adalah drive file mengapa harus bekerja selain drive Temp: ?

sf: mengingatkan saya pada konsep Windows Library - kumpulkan folder dalam suatu entitas.

Karena itu akan membutuhkan sf: untuk menjadi drive di sistem file. Dan beberapa orang tidak menyukai solusi ini karena terlalu kotor, mengganggu, atau apa pun. Juga, baunya My Computer , yang merupakan GUI Windows, yang berarti ada pembunuh di ruangan itu 😲

Jika kita mengizinkan eksekusi variabel secara langsung

Tidak ada _variable_ di sini (yang _value_-nya dapat Anda panggil dengan & ), hanya _literal path_ yang merujuk ke item yang diekspos oleh penyedia Alias (melalui satu-satunya alias: mendorong).

Variabel bernama SCRIPT.PS1 memiliki jalur literal VARIABLE:SCRIPT.PS1 . Jadi, ketika saya mengirimkan VARIABLE:/SCRIPT.PS1 sebagai perintah, saya berharap skrip dalam variabel akan dieksekusi. Tetapi itu tidak diperbolehkan dan saya harus meletakkan skrip ke sistem file agar dapat menjalankannya.

@tokopedia

sf: akan menjadi drive _PowerShell_, tetapi bukan drive _file-system_ PowerShell - saat ini _cannot_ menjadi yang terakhir, karena alasan teknis yang dijelaskan oleh @SeeminglyScience , tetapi bahkan jika bisa (tidak jelas apakah dan kapan), hal itu akan menimbulkan lebih banyak masalah daripada memecahkannya.

(Saya telah menyelesaikan masalah ini: proposal asli adalah untuk _not_ menganggapnya sebagai drive sistem file, lalu kita membahas apa yang diperlukan untuk melakukannya, sekarang saya kembali ke proposal asli).

Sama seperti alias: atau env: bukan _file-system_ drive, sf: tidak akan baik: itu akan menjadi drive yang memperlihatkan item yang mewakili _strings_ yang kebetulan _file -sistem jalur strings_ (seperti banyak variabel lingkungan di Windows berisi jalur sistem file, seperti $env:ProgramFiles ).

Tujuan utama dari drive sf: adalah untuk _enable namespace variable notation_, sehingga sesuatu seperti $sf:Desktop meluas ke _path string_ yang merupakan jalur Desktop sistem file asli yang sesuai platform, dan dapat digunakan apa adanya dalam membangun jalur yang lebih panjang ( $sf:Desktop/file.txt ) dan panggilan yang mengharapkan jalur sistem file asli _baik dalam argumen dan mode ekspresi_.

Sama seperti kebanyakan pengguna yang jarang, jika pernah, berinteraksi dengan drive Env: melalui provider _cmdlets_ - mereka mengandalkan notasi variabel namespace seperti $env:ProgramFiles - mereka hanya akan menggunakan $sf:Desktop , atau pelengkapan tab untuk ditemukan. (Tentu saja, mereka _dapat_ menggunakan Get-ChildItem sf: untuk penemuan yang lebih nyaman dan canggih, jika mereka mau.)

Satu-satunya alasan teknis yang dapat saya pikirkan adalah bahwa SF:/ , tidak seperti TEMP:/ , tidak akan sesuai dengan lokasi sebenarnya, jadi ini akan menjadi drive virtual dengan tautan yang efektif di dalamnya, agak seperti \\.\ , yang merupakan ide menarik lebih baik dibiarkan untuk diimplementasikan oleh OS yang mendasarinya daripada oleh kami sendiri.

@bayu_joo

[...] (catatan: Desktop dan DesktopDir , meskipun secara teknis berbeda, tampaknya merujuk ke lokasi yang sama dalam praktiknya; yang pertama dibedakan dari yang terakhir sebagai "Desktop logis daripada daripada lokasi sistem file fisik "- tidak yakin apa artinya).

• Desktop
• DesktopDirectory

_ Catatan untuk yang belum tahu : Hanya untuk membingungkan, "shell" mengacu pada komponen Windows yang sama sekali berbeda dari PowerShell atau cmd.exe. Anda mungkin mengenalnya sebagai explorer.exe, meskipun secara alami sebagian besar sebenarnya diimplementasikan dalam DLL ..._

Saya pikir perbedaan ini hanya relevan dengan SHGetSpecialFolderLocation dan SHGetFolderLocation , yang membangun jalur di namespace shell (struktur ITEMIDLIST, juga disebut PIDL untuk beberapa alasan). CSIDL_DESKTOP akan memberi Anda hal yang sebenarnya terwakili di desktop Anda; CSIDL_DESKTOPDIRECTORY akan memberi Anda tempat yang Anda tuju ketika Anda mengetik misalnya% USERPROFILE% Desktop ke dalam bilah alamat Explorer.

[Dokumentasi tampaknya menyiratkan bahwa kedua nilai melakukan hal yang sama sejak Vista, tapi saya tidak akan menganggap itu benar.]

Secara khusus, CSIDL_DESKTOP akan memiliki item tambahan apa pun [Komputer, Keranjang Daur Ulang, dll.] Yang telah dikonfigurasi pengguna untuk muncul di desktop, serta item yang dikontribusikan dari CSIDL_COMMON_DESKTOPDIRECTORY (yaitu pintasan desktop Semua Pengguna).

Biasanya, semua ini tidak relevan dengan nilai kembalian System.Environment.GetFolderPath .

apakah ada alasan tidak ada yang mengangkat cmdlet Get-SpecialFolder?

Saya baru saja diarahkan ke masalah ini. Seluruh subjek tentu saja membutuhkan pertimbangan dan desain yang cermat, tetapi ini mungkin dapat membantu seseorang sekarang:

Beberapa tahun yang lalu saya telah membuat modul PS untuk memeriksa dan memanipulasi folder yang dikenal menggunakan COM API (yang menyediakan lebih banyak fungsionalitas daripada API warisan yang digunakan secara internal oleh kelas .NET Environment). Saya ingin meringankan rasa sakit saya saat mengarahkan ulang folder secara massal (termasuk yang Publik) keluar dari drive sistem saat mengatur banyak komputer untuk beberapa anggota keluarga saya - secara default hanya mungkin dengan mengklik di GUI (dan membutuhkan sementara menonaktifkan UAC untuk memindahkan folder Publik). Tujuannya agar bisa menulis

# as any user
Get-KnownFolder | Move-KnownFolder -Destination F:\Profiles\$Env:UserName
# single folder, with rename
Move-KnownFolder -SingleFolder (Get-KnownFolder -Name Personal) -NewPath D:\Data\$Env:UserName\Docs
# as admin
Get-KnownFolder -Public | Move-KnownFolder -Destination F:\Profiles\Public

Modul ini berfungsi penuh (saya cenderung menggunakannya setiap kali saya memasang komputer baru); Saya baru saja kehabisan waktu luang dan motivasi untuk membuat sentuhan akhir - menulis beberapa dokumen / contoh dan menerbitkannya ke PSGallery. Saya mungkin bisa melakukan upaya itu jika ada minat.

Untuk memeriksa jalur yang akan kami gunakan:

PS C:\> (Get-KnownFolder -Name Personal).Path
F:\Profiles\jberezanski\Documents

Implementasi saya jelas hanya untuk Windows; Saya tidak tahu berapa banyak konsep Windows Shell yang berlaku untuk platform lain. Ketika saya berpikir untuk mengekspos lebih banyak konsep tersebut di PS, saya cenderung berpikir dalam istilah penyedia + drive - Shell:\ , dengan root mewakili root namespace Shell (Desktop "logis"). Namun, saya tidak menemukan kasus penggunaan sebenarnya untuk menavigasi namespace itu dan semua kebutuhan praktis saya dipenuhi oleh dua cmdlet yang disebutkan di atas.

(Secara pribadi, saya ingin melihat cara lintas platform untuk mereferensikan folder yang dikenal AppData / Local AppData , sehingga aplikasi dapat berhenti mencemari root direktori profil pengguna dengan config / data mereka file dan folder, tapi itu adalah kata-kata kasar yang berbeda.)

Terima kasih, @jberezanski.

Saya tidak tahu berapa banyak konsep Windows Shell yang berlaku untuk platform lain

Saya telah merangkum folder yang diketahui berlaku untuk platform mana di atas .

Sementara saya berpikir bahwa Get-KnownFolder akan menjadi tambahan yang bagus (saya telah membuat fungsi dengan nama yang sama untuk diri saya sendiri beberapa waktu yang lalu), saya pikir sesuatu seperti $sf:Desktop adalah _also_ dipanggil untuk:

Secara khusus, ini akan mengurangi godaan untuk menulis kode seperti 'hi' > $HOME/Desktop/foo.txt , mengingat bahwa satu-satunya formulasi yang sepenuhnya kuat adalah yang lebih bertele-tele 'hi' > "$(Get-KnownFolder Desktop)/foo.txt" (perhatikan tanda kutip ganda yang diperlukan; Join-Path command akan menjadi lebih bertele-tele).

Mampu menggunakan 'hi' > $sf:Desktop/foo.txt adalah yang terbaik dari kedua dunia: robust _and_ convenient.

Mampu menggunakan 'hi'> $ sf: Desktop / foo.txt adalah yang terbaik dari kedua dunia: kuat dan nyaman.

Sepenuhnya setuju.

Saya juga tidak melihat sintaksnya membingungkan; banyak variabel lingkungan yang umum digunakan berisi jalur dan kami melakukan hal-hal seperti mkdir $Env:TEMP\xyz sepanjang waktu. Saya pikir tidak terlalu sulit untuk mempelajari bahwa awalan lain memberikan akses ke kumpulan jalur tambahan - bahwa penyedia baru sedang bekerja ada detail implementasi, tidak penting dalam kasus penggunaan tipikal hanya ingin mengetahui jalurnya.

Dan, mungkin, _writing_ menjadi $sf:Something bisa melakukan yang setara dengan Move-KnownFolder ...
... atau mungkin tidak, karena akan sangat mudah melakukannya secara tidak sengaja dan pengoperasiannya dapat membahayakan data pengguna.

Ya, saya pikir itu akan terlalu berbahaya, jadi lebih disukai Move-KnownFolder cmdlet, meskipun - tidak seperti Get-KnownFolder - ini akan menjadi khusus Windows.

Omong-omong, Enum Environment + SpecialFolder , yang didasarkan pada fungsi SHGetFolderPath pra-Vista yang lama, kehilangan banyak Folder yang Dikenal yang ditambahkan di Vista dan yang lebih baru (beberapa di antaranya agak berguna), seperti Download, CommonDownloads, SavedPictures, Camera Roll , UserProgramFiles, OneDrive, dan banyak lagi.

Faktanya, API Folder yang Dikenal memungkinkan aplikasi untuk mendaftarkan folder baru dengan sistem, jadi daftar tersebut tidak diperbaiki.

Saya menjalankan ini di sistem saya untuk melihat Folder Diketahui mana dengan jalur tidak kosong yang dicakup oleh metode enum / GetFolderPath SpecialFolder dan dari 95 Folder yang Diketahui tersebut 46 tidak diekspos oleh GetFolderPath:

$specialFolderPaths = [enum]::GetValues([Environment+SpecialFolder]) | % { $p = [Environment]::GetFolderPath($_); [pscustomobject]@{SFName=$_; Path=$p}}
$allKnownFolders = Get-KnownFolder -All
$knownFoldersWithNonEmptyPath = $allKnownFolders | ? Path -ne $null | select Category,Name,CanRedirect,Path
$knownFoldersJoinedWithSpecialFolderPaths = $knownFoldersWithNonEmptyPath | % { $kf = $_; $sfp = $specialFolderPaths | ? Path -eq $kf.Path; $kf | select *,@{Name='SFP';Expression={$sfp}}}
$allKnownFolders | measure | select -expand Count
139
$knownFoldersWithNonEmptyPath | measure | select -expand Count
95
$knownFoldersJoinedWithSpecialFolderPaths | ? SFP -eq $null | measure | select -expand Count
46

Di Windows, saya ingin dapat mengakses semua Folder yang Diketahui yang ada di sistem (implementasi dapat menghitungnya selama inisialisasi). Pada platform lain, set dasar tertentu mungkin harus ditentukan, seperti yang dijelaskan sebelumnya di thread ini (tetapi tidak terbatas pada nilai [Environment + SpecialFolder]).

Satu hal yang perlu diperhatikan - beberapa nama Folder yang Dikenal mengandung spasi ("Rol Kamera"); ini seharusnya tidak menjadi masalah dengan sintaks yang diusulkan, karena kita sudah perlu menangani karakter bermasalah dalam nama variabel lingkungan ( ${Env:ProgramFiles(x86)} ).