ShouldProcess hakkında bilmek istediğiniz her şey

PowerShell işlevleri, kullanıcıların onlarla etkileşim kurma biçimini büyük ölçüde geliştiren çeşitli özelliklere sahiptir. Çoğu zaman gözden kaçırılan önemli özelliklerden biri de -WhatIf ve -Confirm desteğidir ve işlevlerinize eklenmesi kolaydır. Bu yazıda bu özelliğin nasıl uygulanacağına derinlemesine bakacağız.

Not

Bu makalenin orijinal versiyonu @KevinMarquette tarafından yazılan blogda yayınlandı. PowerShell ekibi bu içeriği bizimle paylaştığı için Kevin'e teşekkür ediyor. Lütfen PowerShellExplained.com adresindeki bloguna göz atın.

Bu, ihtiyacı olan kullanıcılara bir güvenlik ağı sağlamak amacıyla işlevlerinizde etkinleştirebileceğiniz basit bir özelliktir. Tehlikeli olabileceğini bildiğiniz bir komutu ilk kez çalıştırmaktan daha korkutucu bir şey yoktur. -WhatIf ile çalıştırma seçeneği büyük bir fark yaratabilir.

CommonParameters

Bu ortak parametrelerin uygulanmasına bakmadan önce, bunların nasıl kullanıldıklarına hızlıca göz atmak istiyorum.

-WhatIf'i kullanma

Bir komut -WhatIf parametresini desteklediğinde, değişiklik yapmak yerine komutun ne yapacağını görmenize olanak tanır. özellikle yıkıcı bir şey yapmadan önce, bir komutun etkisini test etmenin iyi bir yoludur.

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".

Komut ShouldProcess'i doğru bir şekilde uyguluyorsa, yapacağı tüm değişiklikleri size göstermelidir. Burada birden fazla dosyayı silmek için joker karakter kullanan bir örnek verilmiştir.

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".

-Confirm'i kullanma

-WhatIf'i destekleyen komutlar aynı zamanda -Confirm'i de destekler. Bu size bir eylemi gerçekleştirmeden önce onaylama şansı verir.

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"):

Bu durumda devam etmenize, bir değişikliği atlamanıza veya komut dosyasını durdurmanıza olanak tanıyan birden fazla seçeneğiniz vardır. Yardım istemi bu seçeneklerin her birini bunun gibi açıklar.

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"):

Yerelleştirme

Bu istem PowerShell'de yerelleştirilmiştir, böylece dil, işletim sisteminizin diline göre değişir. Bu, PowerShell'in sizin için yönettiği bir şey daha.

Parametreleri değiştir

Bir değeri bir anahtar parametresine aktarmanın yollarına bakmak için kısa bir zaman ayıralım. Bunu belirtmemin ana nedeni, sıklıkla parametre değerlerini çağırdığınız işlevlere aktarmak istemenizdir.

İlk yaklaşım, tüm parametreler için kullanılabilecek belirli bir parametre sözdizimidir ancak bunun çoğunlukla anahtar parametreleri için kullanıldığını görürsünüz. Parametreye değer eklemek için iki nokta üst üste belirtirsiniz.

Remove-Item -Path:* -WhatIf:$true

Aynısını bir değişkenle de yapabilirsiniz.

$DoWhatIf = $true
Remove-Item -Path * -WhatIf:$DoWhatIf

İkinci yaklaşım, değeri belirlemek için bir karma tablosu kullanmaktır.

$RemoveSplat = @{
    Path = '*'
    WhatIf = $true
}
Remove-Item @RemoveSplat

Hashtable'lar veya splatting konusunda yeniyseniz, hashtable'lar hakkında bilmek istediğiniz her şeyi kapsayan başka bir makalem var.

DesteklerShouldProcess

-WhatIf ve -Confirm desteğini etkinleştirmenin ilk adımı, işlevinizin CmdletBinding'inde SupportsShouldProcess'i belirtmektir.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()
    Remove-Item .\myfile1.txt
}

SupportsShouldProcess'i bu şekilde belirterek artık fonksiyonumuzu -WhatIf (veya -Confirm) ile çağırabiliriz.

PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Remove File" on target "C:\Temp\myfile1.txt".

-WhatIf adında bir parametre oluşturmadığıma dikkat edin. SupportsShouldProcess'in belirtilmesi onu bizim için otomatik olarak oluşturur. Test-ShouldProcess üzerinde -WhatIf parametresini belirttiğimizde çağırdığımız bazı şeyler de -WhatIf işlemini gerçekleştirir.

Güven ama doğrula

Burada, çağırdığınız her şeyin -WhatIf değerlerini devraldığına güvenmenin bazı tehlikeleri var. Örneklerin geri kalanı için, bunun işe yaramadığını varsayacağım ve diğer komutlara çağrı yaparken çok açık olacağım. Sizin de aynısını yapmanızı tavsiye ederim.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()
    Remove-Item .\myfile1.txt -WhatIf:$WhatIfPreference
}

Oyundaki tüm parçaları daha iyi anladığınızda nüansları daha sonra tekrar ele alacağım.

$PSCmdlet.ShouldProcess

SupportsShouldProcess'i uygulamanıza izin veren yöntem $PSCmdlet.ShouldProcess'tir. Mantığın bir kısmını işlemeniz gerekip gerekmediğini görmek için $PSCmdlet.ShouldProcess(...)'ı çağırırsınız ve gerisini PowerShell halleder. Bir örnekle başlayalım:

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    $file = Get-ChildItem './myfile1.txt'
    if($PSCmdlet.ShouldProcess($file.Name)){
        $file.Delete()
    }
}

$PSCmdlet.ShouldProcess($file.name) çağrısı, -WhatIf'i (ve -Confirm parametresini) kontrol eder ve ardından bunu uygun şekilde işler. -WhatIf, ShouldProcess'in değişikliğin açıklamasını çıkarmasına ve $false döndürmesine neden olur:

PS> Test-ShouldProcess -WhatIf
What if: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".

-Confirm kullanan bir çağrı, komut dosyasını duraklatır ve kullanıcıya devam etme seçeneği sunar. Kullanıcı Y'yi seçtiyse $true değerini döndürür.

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"):

$PSCmdlet.ShouldProcess'in harika bir özelliği, ayrıntılı çıktı olarak ikiye katlanmasıdır. ShouldProcess'ü uygularken buna sıklıkla güveniyorum.

PS> Test-ShouldProcess -Verbose
VERBOSE: Performing the operation "Test-ShouldProcess" on target "myfile1.txt".

Aşırı yüklemeler

Mesajlaşmayı özelleştirmek için $PSCmdlet.ShouldProcess için farklı parametrelere sahip birkaç farklı aşırı yükleme vardır. Yukarıdaki örnekte ilkini zaten gördük. Şimdi ona daha yakından bakalım.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    if($PSCmdlet.ShouldProcess('TARGET')){
        # ...
    }
}

Bu, hem işlev adını hem de hedefi (parametrenin değeri) içeren çıktı üretir.

What if: Performing the operation "Test-ShouldProcess" on target "TARGET".

İşlem olarak ikinci bir parametrenin belirtilmesi, mesajdaki işlev adı yerine işlem değerini kullanır.

## $PSCmdlet.ShouldProcess('TARGET','OPERATION')
What if: Performing the operation "OPERATION" on target "TARGET".

Bir sonraki seçenek, mesajı tamamen özelleştirmek için üç parametre belirtmektir. Üç parametre kullanıldığında ilki mesajın tamamıdır. İkinci iki parametre hala -Confirm mesaj çıkışında kullanılmaktadır.

## $PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION')
What if: MESSAGE

Hızlı parametre referansı

Buraya sadece hangi parametreleri kullanmanız gerektiğini öğrenmek için geldiyseniz, burada parametrelerin farklı -WhatIf senaryolarında mesajı nasıl değiştirdiğini gösteren hızlı bir referans bulunmaktadır.

## $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

İki parametreli olanı kullanma eğilimindeyim.

İşlem Sebebi Gerekir

Diğerlerine göre daha gelişmiş olan dördüncü bir aşırı yükümüz var. ShouldProcess'in yürütülme nedenini öğrenmenizi sağlar. Bunu buraya yalnızca tamlık sağlamak için ekliyorum çünkü bunun yerine $WhatIfPreference'ın $true olup olmadığını kontrol edebiliriz.

$reason = ''
if($PSCmdlet.ShouldProcess('MESSAGE','TARGET','OPERATION',[ref]$reason)){
    Write-Output "Some Action"
}
$reason

$reason değişkenini [ref] ile referans değişken olarak dördüncü parametreye aktarmamız gerekiyor. ShouldProcess, $reason değerini None veya WhatIf değeriyle doldurur. Bunun yararlı olduğunu söylemedim ve kullanmak için hiçbir nedenim olmadı.

Nereye yerleştirileceği

Komut dosyalarınızı daha güvenli hale getirmek için ShouldProcess'i kullanırsınız. Yani komut dosyalarınızda değişiklik yaparken bunu kullanırsınız. $PSCmdlet.ShouldProcess çağrısını değişikliğe mümkün olduğunca yakın bir yere yerleştirmeyi seviyorum.

## general logic and variable work
if ($PSCmdlet.ShouldProcess('TARGET','OPERATION')){
    # Change goes here
}

Bir öğe koleksiyonunu işliyorsam, onu her öğe için çağırırım. Böylece çağrı foreach döngüsünün içine yerleştirilir.

foreach ($node in $collection){
    # general logic and variable work
    if ($PSCmdlet.ShouldProcess($node,'OPERATION')){
        # Change goes here
    }
}

ShouldProcess'i değişikliğin çevresine sıkı bir şekilde yerleştirmemin nedeni, -WhatIf belirtildiğinde mümkün olduğu kadar çok kodun çalıştırılmasını istememdir. Kullanıcının bu hataları görebilmesi için kurulumun ve doğrulamanın mümkünse çalışmasını istiyorum.

Bunu projelerimi doğrulayan Pester testlerimde de kullanmayı seviyorum. Rahatsız edici bir mantığım varsa, bunu genellikle ShouldProcess içine sarabilir ve testlerimde -WhatIf ile çağırabilirim. Kodunuzun bir kısmını test etmek, hiçbirini test etmemekten daha iyidir.

$WhatIfPreference

Elimizdeki ilk tercih değişkeni $WhatIfPreference'dır. Bu, varsayılan olarak $false'dır. Bunu $true olarak ayarlarsanız, işleviniz -WhatIf'i belirtmişsiniz gibi yürütülür. Bunu oturumunuzda ayarlarsanız, tüm komutlar -WhatIf yürütmesini gerçekleştirir.

-WhatIf ile bir işlevi çağırdığınızda, işlevinizin kapsamı içinde $WhatIfPreference değeri $true olarak ayarlanır.

ConfirmImpact

Örneklerimin çoğu -WhatIf içindir ancak şu ana kadar her şey kullanıcıya bilgi vermek için -Confirm ile de çalışıyor. Fonksiyonun ConfirmImpact değerini yüksek olarak ayarlayabilirsiniz ve kullanıcıya sanki -Confirm ile çağrılmış gibi bilgi verir.

function Test-ShouldProcess {
    [CmdletBinding(
        SupportsShouldProcess,
        ConfirmImpact = 'High'
    )]
    param()

    if ($PSCmdlet.ShouldProcess('TARGET')){
        Write-Output "Some Action"
    }
}

Bu Test-ShouldProcess çağrısı, Yüksek etkisi nedeniyle -Confirm işlemini gerçekleştiriyor.

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

Bariz sorun şu ki, kullanıcıya sormadan diğer komut dosyalarında kullanmanın artık daha zor olması. Bu durumda, istemi bastırmak için -Confirm'e bir $false iletebiliriz.

PS> Test-ShouldProcess -Confirm:$false
Some Action

Daha sonraki bir bölümde -Force desteğinin nasıl ekleneceğini ele alacağım.

$ConfirmPreference

$ConfirmPreference, ConfirmImpact'ın sizden yürütmeyi onaylamanızı istediğini kontrol eden otomatik bir değişkendir. Burada hem $ConfirmPreference hem de ConfirmImpact için olası değerler verilmiştir.

High

Medium

Low

None

Bu değerlerle her işlev için farklı etki düzeyleri belirleyebilirsiniz. $ConfirmPreference değerini ConfirmImpact'tan yüksek bir değere ayarladıysanız, yürütmeyi onaylamanız istenmez.

Varsayılan olarak, $ConfirmPreference Yüksek olarak ayarlanmıştır ve ConfirmImpact Medium olarak ayarlanmıştır. İşlevinizin kullanıcıya otomatik olarak bilgi vermesini istiyorsanız ConfirmImpact ayarınızı Yüksek olarak ayarlayın. Aksi takdirde, yıkıcıysa Medium olarak ayarlayın ve komut üretimde her zaman güvenli bir şekilde çalıştırılacaksa Low kullanın. Bunu none olarak ayarlarsanız, -Confirm belirtilmiş olsa bile soru sormaz (ancak yine de size -WhatIf desteği sağlar).

-Confirm ile bir işlev çağrılırken, işlevinizin kapsamı içinde $ConfirmPreference değeri Low olarak ayarlanır.

İç içe geçmiş onaylama istemlerini bastırma

$ConfirmPreference, çağırdığınız işlevler tarafından algılanabilir. Bu, bir onaylama istemi eklediğiniz ve çağırdığınız işlevin de kullanıcıyı uyardığı senaryolar oluşturabilir.

Yapma eğiliminde olduğum şey, istemi zaten hallettiğimde çağırdığım komutlarda -Confirm:$false belirtmektir.

function Test-ShouldProcess {
    [CmdletBinding(SupportsShouldProcess)]
    param()

    $file = Get-ChildItem './myfile1.txt'
    if($PSCmdlet.ShouldProcess($file.Name)){
        Remove-Item -Path $file.FullName -Confirm:$false
    }
}

Bu bizi daha önceki bir uyarıya geri getiriyor: -WhatIf'in ne zaman bir işleve aktarılmadığı ve -Confirm'in bir işleve ne zaman aktarıldığı konusunda nüanslar vardır. Söz veriyorum bu konuya daha sonra döneceğim.

$PSCmdlet.ShouldContinue

ShouldProcess'in sağladığından daha fazla kontrole ihtiyacınız varsa istemi doğrudan ShouldContinue ile tetikleyebilirsiniz. ShouldContinue, $ConfirmPreference, ConfirmImpact, -Confirm, $WhatIfPreference ve < kodunu yok sayar-WhatIf çünkü her yürütüldüğünde sorar.

Hızlı bir bakışta ShouldProcess ile ShouldContinue'yu karıştırmak kolaydır. Parametrenin CmdletBinding'de SupportsShouldProcess olarak adlandırılması nedeniyle ShouldProcess kullanmayı hatırlıyorum. Hemen hemen her senaryoda ShouldProcess kullanmalısınız. Bu yüzden ilk önce bu yöntemi ele aldım.

Şimdi ShouldContinue'a uygulamalı olarak göz atalım.

function Test-ShouldContinue {
    [CmdletBinding()]
    param()

    if($PSCmdlet.ShouldContinue('TARGET','OPERATION')){
        Write-Output "Some Action"
    }
}

Bu bize daha az seçenekle daha basit bir istem sağlar.

Test-ShouldContinue

Second
TARGET
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):

ShouldContinue ile ilgili en büyük sorun, kullanıcıya her zaman bilgi verdiği için kullanıcının onu etkileşimli olarak çalıştırmasını gerektirmesidir. Her zaman diğer komut dosyaları tarafından kullanılabilecek araçlar geliştiriyor olmalısınız. Bunu yapmanın yolu -Force'u uygulamaktır. Bu fikre daha sonra tekrar değineceğim.

Herkese evet

Bu, ShouldProcess ile otomatik olarak gerçekleştirilir ancak ShouldContinue için biraz daha çalışmamız gerekir. Mantığı kontrol etmek için birkaç değeri referans olarak aktarmamız gereken ikinci bir yöntem aşırı yükü var.

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]"
        }
    }
}

Bunu çalışırken göstermek için bir foreach döngüsü ve bir koleksiyon ekledim. Okumayı kolaylaştırmak için if ifadesinden ShouldContinue çağrısını çıkardım. Dört parametreli bir yöntemi çağırmak biraz çirkinleşmeye başladı ama elimden geldiğince temiz görünmesini sağlamaya çalıştım.

Uygulama -Kuvvet

ShouldProcess ve ShouldContinue'nun -Force'u farklı şekillerde uygulaması gerekir. Bu uygulamaların püf noktası, ShouldProcess'in her zaman çalıştırılması gerektiği, ancak -Force belirtilirse ShouldContinue'nin çalıştırılmaması gerektiğidir.

ShouldProcess -Force

ConfirmImpact'ınızı yüksek olarak ayarlarsanız, kullanıcılarınızın deneyeceği ilk şey onu -Force ile bastırmaktır. Zaten yapacağım ilk şey bu.

Test-ShouldProcess -Force
Error: Test-ShouldProcess: A parameter cannot be found that matches parameter name 'force'.

ConfirmImpact bölümünden hatırlarsanız aslında şu şekilde çağırmaları gerekiyor:

Test-ShouldProcess -Confirm:$false

Herkes bunu yapmaları gerektiğinin farkında değil ve -Force, ShouldContinue'u bastırmaz. Bu nedenle kullanıcılarımızın akıl sağlığı için -Force'u uygulamalıyız. Buradaki tam örneğe bir göz atın:

function Test-ShouldProcess {
    [CmdletBinding(
        SupportsShouldProcess,
        ConfirmImpact = 'High'
    )]
    param(
        [Switch]$Force
    )

    if ($Force -and -not $Confirm){
        $ConfirmPreference = 'None'
    }

    if ($PSCmdlet.ShouldProcess('TARGET')){
        Write-Output "Some Action"
    }
}

Parametre olarak kendi -Force anahtarımızı ekliyoruz. CmdletBinding'de SupportsShouldProcess kullanıldığında -Confirm parametresi otomatik olarak eklenir.

[CmdletBinding(
    SupportsShouldProcess,
    ConfirmImpact = 'High'
)]
param(
    [Switch]$Force
)

Burada -Force mantığına odaklanıyoruz:

if ($Force -and -not $Confirm){
    $ConfirmPreference = 'None'
}

Kullanıcı -Force belirtirse, aynı zamanda -Confirm belirtmediği sürece onaylama istemini gizlemek isteriz. Bu, kullanıcının bir değişikliği zorlamasına ancak yine de değişikliği onaylamasına olanak tanır. Daha sonra yerel kapsamda $ConfirmPreference ayarını yapıyoruz. Artık -Force parametresinin kullanılması $ConfirmPreference değerini geçici olarak yok olarak ayarlayarak onay istemini devre dışı bırakır.

if ($PSCmdlet.ShouldProcess('TARGET')){
        Write-Output "Some Action"
    }

Birisi hem -Force hem de -WhatIf belirtirse -WhatIf'in öncelik alması gerekir. Bu yaklaşım -WhatIf işlemini korur çünkü ShouldProcess her zaman yürütülür.

if ifadesinin içine $Force değeri için ShouldProcess ile bir kontrol eklemeyin. Her ne kadar ShouldContinue için bir sonraki bölümde size göstereceğim şey bu olsa da, bu, bu spesifik senaryo için bir anti-modeldir.

ShouldContinue -Force

Bu, -Force'u ShouldContinue ile uygulamanın doğru yoludur.

function Test-ShouldContinue {
    [CmdletBinding()]
    param(
        [Switch]$Force
    )

    if($Force -or $PSCmdlet.ShouldContinue('TARGET','OPERATION')){
        Write-Output "Some Action"
    }
}

$Force, -or operatörünün soluna yerleştirildiğinde ilk önce değerlendirilir. Bu şekilde yazmak, if ifadesinin yürütülmesine kısa devre yaptırır. $force $true ise, ShouldContinue yürütülmez.

PS> Test-ShouldContinue -Force
Some Action

Bu senaryoda -Confirm veya -WhatIf hakkında endişelenmemize gerek yok çünkü bunlar ShouldContinue tarafından desteklenmiyor. Bu nedenle ShouldProcess'ten farklı şekilde ele alınması gerekir.

Kapsam sorunları

-WhatIf ve -Confirm kullanmanın, işlevlerinizin içindeki her şeye ve çağırdıkları her şeye uygulanması gerekir. Bunu, yerel kapsamda $WhatIfPreference'ı $true olarak ayarlayarak veya $ConfirmPreference'ı Low olarak ayarlayarak yaparlar. işlev. Başka bir işlevi çağırdığınızda, ShouldProcess çağrıları bu değerleri kullanır.

Bu aslında çoğu zaman doğru şekilde çalışır. Yerleşik cmdlet'i veya aynı kapsamınızdaki bir işlevi her çağırdığınızda çalışır. Ayrıca konsoldan bir komut dosyası veya komut dosyası modülündeki bir işlevi çağırdığınızda da çalışır.

Çalışmadığı tek yer, bir betiğin veya bir betik modülünün başka bir betik modülündeki bir işlevi çağırmasıdır. Bu büyük bir sorun gibi görünmeyebilir ancak PSGallery'de oluşturduğunuz veya buradan aldığınız modüllerin çoğu komut dosyası modülleridir.

Temel sorun, komut dosyası modüllerinin, diğer komut dosyası modüllerindeki işlevlerden çağrıldığında $WhatIfPreference veya $ConfirmPreference (ve diğer birkaçı) için değerleri devralmamasıdır.

Bunu genel bir kural olarak özetlemenin en iyi yolu, bunun ikili modüller için doğru şekilde çalışması ve komut dosyası modülleri için çalışacağına asla güvenmemektir. Emin değilseniz ya test edin ya da düzgün çalışmadığını varsayın.

Kişisel olarak bunun çok tehlikeli olduğunu düşünüyorum çünkü bu durum, ayrı ayrı doğru şekilde çalışan ancak birbirlerini çağırdıklarında düzgün şekilde çalışmayan birden fazla modüle -WhatIf desteği eklediğiniz senaryolar yaratıyor.

Bu sorunu çözmek için çalışan bir GitHub RFC'miz var. Daha fazla ayrıntı için Yürütme tercihlerini betik modülü kapsamının ötesine yayma konusuna bakın.

Kapanışta

Her kullanmam gerektiğinde ShouldProcess'in nasıl kullanılacağına bakmam gerekiyor. ShouldProcess'ı ShouldContinue'dan ayırt etmek uzun zamanımı aldı. Neredeyse her zaman hangi parametrelerin kullanılacağına bakmam gerekiyor. Bu yüzden hala zaman zaman kafanız karışırsa endişelenmeyin. Bu makale ihtiyacınız olduğunda burada olacak. Eminim ki ben de buna sık sık başvuracağım.

Bu yazıyı beğendiyseniz lütfen aşağıdaki bağlantıyı kullanarak düşüncelerinizi Twitter'da benimle paylaşın. İçeriğimden değer elde eden insanlardan haber almak her zaman hoşuma gider.