Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Fungsi PowerShell memiliki beberapa fitur yang sangat meningkatkan cara pengguna berinteraksi dengan mereka.
Salah satu fitur penting yang sering diabaikan adalah -WhatIf dan dukungan -Confirm, yang dengan mudah dapat ditambahkan ke fungsi Anda. Dalam artikel ini, kami mendalami cara mengimplementasikan fitur ini.
Catatan
Versi asli artikel ini muncul di blog yang ditulis oleh @KevinMarquette. Tim PowerShell berterima kasih kepada Kevin karena telah membagikan konten ini kepada kami. Silakan lihat blognya di PowerShellExplained.com.
Ini adalah fitur sederhana yang dapat Anda aktifkan dalam fungsi Anda untuk menyediakan jaring pengaman bagi pengguna yang membutuhkannya. Tidak ada yang lebih menakutkan daripada menjalankan perintah yang Anda tahu bisa berbahaya untuk pertama kalinya. Opsi untuk menjalankannya dengan -WhatIf dapat membuat perbedaan besar.
CommonParameters
Sebelum kita melihat penerapan parameter umum ini , saya ingin melihat sekilas bagaimana parameter tersebut digunakan.
Menggunakan -WhatIf
Ketika perintah mendukung -WhatIf parameter , perintah ini memungkinkan Anda untuk melihat apa yang akan dilakukan perintah alih-alih membuat perubahan. ini adalah cara yang baik untuk menguji dampak perintah, terutama sebelum Anda melakukan sesuatu yang merusak.
PS C:\temp> Get-ChildItem
Directory: C:\temp
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 4/19/2021 8:59 AM 0 importantfile.txt
-a---- 4/19/2021 8:58 AM 0 myfile1.txt
-a---- 4/19/2021 8:59 AM 0 myfile2.txt
PS C:\temp> Remove-Item -Path .\myfile1.txt -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
Jika perintah mengimplementasikan ShouldProcessdengan benar , perintah tersebut akan menunjukkan kepada Anda semua perubahan yang akan dilakukannya. Berikut adalah contoh menggunakan kartubebas untuk menghapus beberapa file.
PS C:\temp> Remove-Item -Path * -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
What if: Performing the operation "Remove File" on target "C:\Temp\myfile2.txt".
What if: Performing the operation "Remove File" on target "C:\Temp\importantfile.txt".
Menggunakan -Confirm
Perintah yang mendukung -WhatIf juga mendukung -Confirm. Ini memberi Anda kesempatan mengonfirmasi tindakan sebelum melakukannya.
PS C:\temp> Remove-Item .\myfile1.txt -Confirm
Confirm
Are you sure you want to perform this action?
Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Dalam hal ini, Anda memiliki beberapa opsi yang memungkinkan Anda untuk melanjutkan, melewati perubahan, atau menghentikan skrip. Perintah bantuan menjelaskan masing-masing opsi seperti ini.
Y - Continue with only the next step of the operation.
A - Continue with all the steps of the operation.
N - Skip this operation and proceed with the next operation.
L - Skip this operation and all subsequent operations.
S - Pause the current pipeline and return to the command prompt. Type "exit" to resume the pipeline.
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Lokalisasi
Perintah ini dilokalkan di PowerShell sehingga bahasa berubah berdasarkan bahasa sistem operasi Anda. Ini adalah satu hal lagi yang dikelola PowerShell untuk Anda.
[switch] parameter
Mari kita luangkan waktu sejenak untuk melihat cara meneruskan nilai ke [switch] parameter. Alasan utama saya memanggil ini adalah bahwa Anda sering ingin meneruskan nilai parameter ke fungsi yang Anda panggil.
Pendekatan pertama adalah sintaks parameter tertentu yang dapat digunakan untuk semua parameter tetapi Anda sebagian besar melihatnya digunakan untuk [switch] parameter. Anda menentukan titik dua untuk mengaitkan nilai dengan parameter.
Remove-Item -Path:* -WhatIf:$true
Anda dapat melakukan hal yang sama dengan variabel.
$DoWhatIf = $true
Remove-Item -Path * -WhatIf:$DoWhatIf
Pendekatan kedua adalah menggunakan hashtable untuk menguraikan nilai.
$RemoveSplat = @{
Path = '*'
WhatIf = $true
}
Remove-Item @RemoveSplat
Jika Anda baru mengenal hashtable atau splatting, saya memiliki artikel lain tentang yang mencakup semua yang ingin Anda ketahui tentang hashtable.
MendukungPemrosesan
Langkah pertama untuk mengaktifkan dukungan -WhatIf dan -Confirm adalah menentukan SupportsShouldProcess dalam fungsi CmdletBinding Anda.
function Test-ShouldProcess {
[CmdletBinding(SupportsShouldProcess)]
param()
Remove-Item .\myfile1.txt
}
Dengan menentukan SupportsShouldProcess dengan cara ini, kita sekarang dapat memanggil fungsi kita dengan -WhatIf (atau -Confirm).
PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".
Perhatikan bahwa saya tidak membuat parameter yang disebut -WhatIf. Menentukan SupportsShouldProcess secara otomatis membuatnya untuk kami. Ketika kita menentukan -WhatIf parameter pada Test-ShouldProcess, beberapa hal yang kita sebut juga melakukan -WhatIf pemrosesan.
Catatan
Saat Anda menggunakan SupportsShouldProcess, PowerShell tidak menambahkan $WhatIf variabel ke fungsi . Anda tidak perlu memeriksa nilai $WhatIf karena ShouldProcess() metode mengurusnya untuk Anda.
Percayai tetapi verifikasi
Ada beberapa bahaya dalam mempercayai bahwa semua yang Anda anggap mewarisi nilai dari -WhatIf. Untuk contoh lainnya, saya akan berasumsi bahwa itu tidak berfungsi dan sangat eksplisit saat melakukan panggilan ke perintah lain. Saya sarankan Anda melakukan hal yang sama.
function Test-ShouldProcess {
[CmdletBinding(SupportsShouldProcess)]
param()
Remove-Item .\myfile1.txt -WhatIf:$WhatIfPreference
}
Saya akan mengulas kembali nuansa tersebut nanti setelah Anda memiliki pemahaman yang lebih baik tentang semua elemen dalam keseluruhan situasi.
$PSCmdlet.ShouldProcess
Metode yang memungkinkan Anda untuk menerapkan SupportsShouldProcess adalah $PSCmdlet.ShouldProcess. Anda memanggil $PSCmdlet.ShouldProcess(...) untuk melihat apakah Anda harus memproses beberapa logika dan PowerShell mengurus sisanya. Mari kita mulai dengan contoh:
function Test-ShouldProcess {
[CmdletBinding(SupportsShouldProcess)]
param()
$file = Get-ChildItem './myfile1.txt'
if($PSCmdlet.ShouldProcess($file.Name)){
$file.Delete()
}
}
Panggilan untuk $PSCmdlet.ShouldProcess($file.Name) memeriksa -WhatIf (dan -Confirm parameter) kemudian menanganinya dengan sesuai.
-WhatIf menyebabkan ShouldProcess menghasilkan deskripsi perubahan kemudian mengembalikan $false:
PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".
Panggilan menggunakan -Confirm akan menghentikan skrip sementara dan memberikan opsi kepada pengguna untuk melanjutkan. Ini mengembalikan $true jika pengguna memilih Y.
PS> Test-ShouldProcess -Confirm
Confirm
Are you sure you want to perform this action?
Performing the operation "Test-ShouldProcess" on target "myfile1.txt".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"):
Fitur luar biasa dari $PSCmdlet.ShouldProcess adalah bahwa ia juga berfungsi sebagai output verbose. Saya sering bergantung pada ini saat menerapkan ShouldProcess.
PS> Test-ShouldProcess -Verbose
VERBOSE: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".
Overload
Ada beberapa overload yang berbeda untuk $PSCmdlet.ShouldProcess dengan parameter yang berbeda untuk menyesuaikan pengiriman pesan. Kami sudah melihat yang pertama dalam contoh di atas. Mari kita lihat lebih dekat.
function Test-ShouldProcess {
[CmdletBinding(SupportsShouldProcess)]
param()
if($PSCmdlet.ShouldProcess('TARGET')){
# ...
}
}
Ini menghasilkan output yang mencakup nama fungsi dan target (nilai parameter).
What if: Performing the operation "Test-ShouldProcess" on target "TARGET".
Menentukan parameter kedua karena operasi menggunakan nilai operasi alih-alih nama fungsi dalam pesan.
## $PSCmdlet.ShouldProcess('TARGET','OPERATION')
What if: Performing the operation "OPERATION" on target "TARGET".
Opsi berikutnya adalah menentukan tiga parameter untuk mengkustomisasi pesan sepenuhnya. Ketika tiga parameter digunakan, yang pertama adalah seluruh pesan. Dua parameter kedua masih digunakan dalam -Confirm output pesan.
## $PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION')
What if: MESSAGE
Referensi parameter cepat
Untuk berjaga-jaga jika Anda datang ke sini hanya untuk mencari tahu parameter apa yang harus Anda gunakan, berikut adalah referensi cepat yang menunjukkan bagaimana parameter mengubah pesan dalam skenario yang berbeda -WhatIf .
## $PSCmdlet.ShouldProcess('TARGET')
What if: Performing the operation "FUNCTION_NAME" on target "TARGET".
## $PSCmdlet.ShouldProcess('TARGET','OPERATION')
What if: Performing the operation "OPERATION" on target "TARGET".
## $PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION')
What if: MESSAGE
Saya cenderung menggunakan yang dengan dua parameter.
AlasanHarusDiproses
Kami memiliki penambahan beban keempat yang lebih canggih dibandingkan yang lainnya. Ini memungkinkan Anda mendapatkan alasan mengapa ShouldProcess dijalankan. Saya hanya menambahkan ini di sini untuk kelengkapan karena kita dapat memeriksa apakah $WhatIfPreference itu $true sebagai gantinya.
$reason = ''
if($PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION',[ref]$reason)){
Write-Output "Some Action"
}
$reason
Kita harus meneruskan $reason variabel ke parameter keempat sebagai variabel referensi dengan [ref].
ShouldProcess mengisi $reason dengan nilai None atau WhatIf. Saya tidak mengatakan ini berguna dan saya tidak punya alasan untuk menggunakannya.
Di mana menempatkannya
Anda menggunakan ShouldProcess untuk membuat skrip Anda lebih aman. Jadi Anda menggunakannya saat skrip Anda membuat perubahan. Saya suka menempatkan $PSCmdlet.ShouldProcess panggilan sedekat mungkin dengan perubahan.
## general logic and variable work
if ($PSCmdlet.ShouldProcess('TARGET','OPERATION')){
# Change goes here
}
Jika saya memproses kumpulan item, saya memanggilnya pada setiap item. Jadi panggilan akan ditempatkan di dalam perulangan foreach .
foreach ($node in $collection){
# general logic and variable work
if ($PSCmdlet.ShouldProcess($node,'OPERATION')){
# Change goes here
}
}
Alasan mengapa saya menempatkan ShouldProcess erat di sekitar perubahan, adalah bahwa saya ingin sebanyak mungkin kode untuk dijalankan ketika -WhatIf ditentukan. Saya ingin penyiapan dan validasi berjalan jika memungkinkan sehingga pengguna dapat melihat kesalahan tersebut.
Saya juga ingin menggunakan ini dalam tes Pester saya yang memvalidasi proyek saya. Jika saya memiliki sepotong logika yang sulit ditiru dalam Pester, saya sering dapat membungkusnya dengan ShouldProcess dan memanggilnya menggunakan -WhatIf dalam tes saya. Lebih baik menguji sebagian kode Anda daripada tidak sama sekali.
$WhatIfPreference
Variabel preferensi pertama yang kita miliki adalah $WhatIfPreference. Ini $false secara default. Jika Anda mengaturnya ke $true maka fungsi Anda dijalankan seolah-olah Anda menentukan -WhatIf. Jika Anda menyetel ini dalam sesi Anda, semua perintah akan mengeksekusi -WhatIf.
Saat Anda memanggil fungsi dengan -WhatIf, nilai $WhatIfPreference diatur ke $true di dalam cakupan fungsi Anda.
ConfirmImpact
Sebagian besar contoh saya adalah untuk -WhatIf, tetapi sejauh ini semuanya juga berfungsi dengan -Confirm untuk memberi arahan kepada pengguna. Anda dapat mengatur ConfirmImpact fungsi ke tingkat tinggi yang meminta pengguna seolah-olah fungsi tersebut dipanggil dengan -Confirm.
function Test-ShouldProcess {
[CmdletBinding(
SupportsShouldProcess,
ConfirmImpact = 'High'
)]
param()
if ($PSCmdlet.ShouldProcess('TARGET')){
Write-Output "Some Action"
}
}
Panggilan ke Test-ShouldProcess ini melakukan aksi -Confirm karena dampaknya High.
PS> Test-ShouldProcess
Confirm
Are you sure you want to perform this action?
Performing the operation "Test-ShouldProcess" on target "TARGET".
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y
Some Action
Masalah yang jelas adalah bahwa sekarang lebih sulit digunakan dalam skrip lain tanpa harus meminta pengguna. Dalam hal ini, kita dapat meneruskan $false ke -Confirm untuk menekan prompt.
PS> Test-ShouldProcess -Confirm:$false
Some Action
Saya akan membahas cara menambahkan -Force dukungan di bagian selanjutnya.
$ConfirmPreference
$ConfirmPreference adalah variabel otomatis yang mengontrol ketika ConfirmImpact meminta Anda untuk mengonfirmasi eksekusi. Berikut adalah nilai yang mungkin untuk $ConfirmPreference dan ConfirmImpact.
HighMediumLowNone
Dengan nilai-nilai ini, Anda dapat menentukan tingkat dampak yang berbeda untuk setiap fungsi. Jika Anda telah $ConfirmPreference mengatur ke nilai yang lebih tinggi dari ConfirmImpact, maka Anda tidak diminta untuk mengonfirmasi eksekusi.
Secara default, $ConfirmPreference diatur ke High dan ConfirmImpact adalah Medium. Jika Anda ingin fungsi Anda secara otomatis menginstruksikan pengguna, atur ConfirmImpact ke High. Jika tidak, tetapkan ke Medium jika bersifat merusak dan gunakan Low jika perintah selalu aman dijalankan di lingkungan produksi. Jika Anda mengaturnya ke none, itu tidak akan meminta meskipun -Confirm telah ditentukan (tetapi masih memberikan dukungan -WhatIf).
Saat memanggil fungsi dengan -Confirm, nilai $ConfirmPreference diatur ke Low di dalam cakupan fungsi Anda.
Menyembunyikan prompt konfirmasi bertingkat
$ConfirmPreference dapat digunakan oleh fungsi yang Anda panggil. Ini dapat membuat skenario di mana Anda menambahkan permintaan konfirmasi dan fungsi yang Anda panggil juga meminta pengguna.
Apa yang cenderung saya lakukan adalah menentukan -Confirm:$false pada perintah yang saya panggil ketika saya telah menangani permintaan.
function Test-ShouldProcess {
[CmdletBinding(SupportsShouldProcess)]
param()
$file = Get-ChildItem './myfile1.txt'
if($PSCmdlet.ShouldProcess($file.Name)){
Remove-Item -Path $file.FullName -Confirm:$false
}
}
Ini membawa kita kembali ke peringatan sebelumnya: Ada nuansa kapan -WhatIf tidak diteruskan ke fungsi dan ketika -Confirm diteruskan ke fungsi. Aku berjanji aku akan kembali ke ini nanti.
$PSCmdlet.ShouldContinue
Jika Anda membutuhkan lebih banyak kontrol daripada ShouldProcess yang disediakan, Anda dapat memicu perintah langsung dengan ShouldContinue.
ShouldContinue mengabaikan $ConfirmPreference, ConfirmImpact, -Confirm, $WhatIfPreference, dan -WhatIf karena memunculkan permintaan setiap kali dijalankan.
Sekilas, mudah untuk membingungkan ShouldProcess dan ShouldContinue. Saya cenderung ingat untuk menggunakan ShouldProcess karena parameter dipanggil SupportsShouldProcess di CmdletBinding.
Anda harus menggunakan ShouldProcess hampir setiap skenario. Itulah sebabnya saya membahas metode itu terlebih dahulu.
Mari kita lihat ShouldContinue sedang beroperasi.
function Test-ShouldContinue {
[CmdletBinding()]
param()
if($PSCmdlet.ShouldContinue('TARGET','OPERATION')){
Write-Output "Some Action"
}
}
Ini memberi kita perintah yang lebih sederhana dengan lebih sedikit opsi.
Test-ShouldContinue
Second
TARGET
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"):
Masalah terbesar dengan ShouldContinue adalah bahwa pengguna diharuskan untuk menjalankannya secara interaktif karena ShouldContinue selalu meminta pengguna. Anda harus selalu membangun alat yang dapat digunakan oleh skrip lain. Cara Anda melakukan ini adalah dengan menerapkan -Force. Aku akan mempertimbangkan ulang ide ini nanti.
Ya untuk semua
Ini secara otomatis ditangani dengan ShouldProcess tetapi kita harus melakukan sedikit lebih banyak pekerjaan untuk ShouldContinue. Ada kelebihan beban metode kedua di mana kita harus meneruskan beberapa nilai dengan referensi untuk mengontrol logika.
function Test-ShouldContinue {
[CmdletBinding()]
param()
$collection = 1..5
$yesToAll = $false
$noToAll = $false
foreach($target in $collection) {
$continue = $PSCmdlet.ShouldContinue(
"TARGET_$target",
'OPERATION',
[ref]$yesToAll,
[ref]$noToAll
)
if ($continue){
Write-Output "Some Action [$target]"
}
}
}
Saya menambahkan perulangan foreach dan koleksi untuk menunjukkannya dalam tindakan. Saya menarik panggilan ShouldContinue dari pernyataan if untuk membuatnya lebih mudah dibaca. Memanggil metode dengan empat parameter mulai menjadi sedikit jelek, tetapi saya mencoba membuatnya terlihat sebersih yang saya bisa.
Menerapkan -Force
ShouldProcess dan ShouldContinue perlu menerapkan -Force dengan cara yang berbeda. Trik untuk implementasi ini adalah bahwa ShouldProcess harus selalu dijalankan, tetapi ShouldContinue tidak boleh dijalankan jika -Force ditentukan.
ShouldProcess -Force
Jika Anda mengatur ConfirmImpact ke high, hal pertama yang akan dicoba pengguna Anda adalah menonaktifkannya dengan -Force. Itu hal pertama yang kulakukan.
Test-ShouldProcess -Force
Error: Test-ShouldProcess: A parameter cannot be found that matches parameter name 'force'.
Jika Anda ingat dari bagian ConfirmImpact, mereka benar-benar perlu memanggilnya seperti ini:
Test-ShouldProcess -Confirm:$false
Tidak semua orang menyadari bahwa mereka perlu melakukan itu dan -Force tidak menekan ShouldContinue.
Jadi kita harus menerapkan -Force untuk kewarasan pengguna kita. Lihat contoh lengkap ini di sini:
function Test-ShouldProcess {
[CmdletBinding(
SupportsShouldProcess,
ConfirmImpact = 'High'
)]
param(
[switch]$Force
)
if ($Force -and -not $PSBoundParameters.ContainsKey('Confirm')) {
$ConfirmPreference = 'None'
}
if ($PSCmdlet.ShouldProcess('TARGET')) {
Write-Output "Some Action"
}
}
Kami menambahkan sakelar buatan kami sendiri -Force sebagai parameter. Parameter -Confirm secara otomatis ditambahkan saat menggunakan SupportsShouldProcess di CmdletBinding. Namun, saat Anda menggunakan SupportsShouldProcess, PowerShell tidak menambahkan $Confirm variabel ke fungsi . Jika Anda berjalan dalam Mode Ketat dan mencoba menggunakan $Confirm variabel sebelum ditentukan, Anda mendapatkan kesalahan. Untuk menghindari kesalahan, Anda dapat menggunakan $PSBoundParameters untuk menguji apakah parameter diteruskan oleh pengguna.
if ($Force -and -not $PSBoundParameters.ContainsKey('Confirm')) {
$ConfirmPreference = 'None'
}
Jika pengguna menentukan -Force kita mengatur $ConfirmPreference ke None dalam cakupan lokal. Jika pengguna juga menentukan -Confirm , maka ShoudProcess() menghormati nilai -Confirm parameter.
if ($PSCmdlet.ShouldProcess('TARGET')){
Write-Output "Some Action"
}
Jika seseorang menentukan -Force dan -WhatIf, maka -WhatIf perlu diprioritaskan. Pendekatan ini tetap mempertahankan pemrosesan -WhatIf karena ShouldProcess selalu dijalankan.
Jangan tambahkan pengujian untuk nilai $Force di dalam pernyataan if dengan ShouldProcess. Itu adalah pola yang tidak disarankan untuk skenario spesifik ini, meskipun saya akan menunjukkan itu di bagian berikutnya untuk ShouldContinue.
ShouldContinue -Force
Ini adalah cara yang benar untuk menerapkan -Force dengan ShouldContinue.
function Test-ShouldContinue {
[CmdletBinding()]
param(
[switch]$Force
)
if($Force -or $PSCmdlet.ShouldContinue('TARGET','OPERATION')){
Write-Output "Some Action"
}
}
Dengan menempatkan $Force di sebelah kiri operator -or, operator tersebut akan dievaluasi terlebih dahulu. Menulisnya dengan cara ini menghentikan eksekusi pernyataan if. Jika $Force adalah $true, maka ShouldContinue tidak dijalankan.
PS> Test-ShouldContinue -Force
Some Action
Kita tidak perlu khawatir tentang -Confirm atau -WhatIf dalam skenario ini karena mereka tidak didukung oleh ShouldContinue. Inilah sebabnya mengapa perlu ditangani secara berbeda dari ShouldProcess.
Masalah cakupan
Menggunakan -WhatIf dan -Confirm seharusnya berlaku untuk semua yang ada di dalam fungsi Anda dan semua yang dipanggil oleh fungsi tersebut. Mereka melakukan ini dengan mengatur $WhatIfPreference ke $true atau mengatur $ConfirmPreference ke Low dalam cakupan lokal fungsi. Saat Anda memanggil fungsi lain, panggilan untuk ShouldProcess menggunakan nilai tersebut.
Ini benar-benar bekerja dengan benar sebagian besar waktu. Setiap kali Anda memanggil cmdlet bawaan atau fungsi dalam cakupan yang sama, cmdlet tersebut berfungsi. Ini juga berfungsi saat Anda memanggil skrip atau fungsi dalam modul skrip dari konsol.
Satu tempat tertentu di mana tidak berfungsi adalah ketika skrip atau modul skrip memanggil fungsi di modul skrip lain. Ini mungkin tidak terdengar seperti masalah besar, tetapi sebagian besar modul yang Anda buat atau tarik dari PSGallery adalah modul skrip.
Masalah intinya adalah bahwa modul skrip tidak mewarisi nilai untuk $WhatIfPreference atau $ConfirmPreference (dan beberapa lainnya) ketika dipanggil dari fungsi dalam modul skrip lainnya.
Cara terbaik untuk meringkas ini sebagai aturan umum adalah bahwa ini berfungsi dengan benar untuk modul biner dan tidak pernah mempercayainya untuk bekerja untuk modul skrip. Jika Anda tidak yakin, uji atau asumsikan tidak berfungsi dengan benar.
Saya merasa hal ini sangat berbahaya karena menciptakan skenario di mana Anda menambahkan dukungan -WhatIf ke modul-modul yang bekerja dengan benar secara terpisah, namun gagal bekerja dengan benar ketika saling berinteraksi.
Kami memiliki GitHub RFC yang bekerja untuk memperbaiki masalah ini. Lihat Menyebarkan preferensi eksekusi di luar cakupan modul skrip untuk detail selengkapnya.
Sebagai penutup
Saya harus mencari cara menggunakan ShouldProcess setiap kali saya perlu menggunakannya. Butuh waktu lama untuk membedakan ShouldProcess dari ShouldContinue. Saya hampir selalu perlu mencari parameter apa yang akan digunakan. Jadi jangan khawatir jika Anda masih bingung dari waktu ke waktu. Artikel ini akan berada di sini ketika Anda membutuhkannya. Saya yakin saya akan sering merujuknya sendiri.
Jika Anda menyukai posting ini, silakan bagikan pemikiran Anda dengan saya di Twitter menggunakan tautan di bawah ini. Saya selalu suka mendengar dari orang-orang yang mendapatkan nilai dari konten saya.
Berkolaborasi dengan kami di GitHub
Sumber untuk konten ini dapat ditemukan di GitHub, yang juga dapat Anda gunakan untuk membuat dan meninjau masalah dan menarik permintaan. Untuk informasi selengkapnya, lihat panduan kontributor kami.
