ShouldProcess에 대해 알고 싶은 모든 것

PowerShell 함수에는 사용자가 상호 작용하는 방식을 크게 개선하는 몇 가지 기능이 있습니다. 종종 -WhatIf와 -Confirm 지원이라는 중요한 기능이 간과되지만, 이를 함수에 쉽게 추가할 수 있습니다. 이 문서에서는 이 기능을 구현하는 방법을 자세히 알아보세요.

참고 사항

현재 문서의 원본 버전은 @KevinMarquette가 작성한 블로그에 있습니다. PowerShell 팀은 이 콘텐츠를 공유해 주신 Kevin에게 감사드립니다. PowerShellExplained.com에 있는 그의 블로그를 확인하세요.

이 기능은 함수에서 사용하도록 설정하여 필요한 사용자에게 안전망을 제공할 수 있는 간단한 기능입니다. 처음으로 위험할 수 있다는 것을 알고 있는 명령을 실행하는 것보다 무서운 것은 없습니다. 함께 실행하는 -WhatIf 옵션은 큰 차이를 만들 수 있습니다.

CommonParameters

이러한 일반적인 매개 변수 구현을 살펴보기 전에 이러한 매개 변수의 사용 방법을 간단히 살펴보겠습니다.

-WhatIf 사용

명령이 매개 변수를 -WhatIf 지원하는 경우 명령을 변경하는 대신 명령이 수행한 작업을 확인할 수 있습니다. 문제가 될 수 있는 작업을 하기 전에 명령이 미칠 영향을 테스트하면 도움이 됩니다.

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

ShouldProcess 명령을 올바르게 구현한 경우, 수행했을 경우의 모든 변경 사항을 표시해야 합니다. 다음은 와일드카드를 사용하여 여러 파일을 삭제하는 예제입니다.

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 사용

-WhatIf를 지원하는 명령은 -Confirm도 지원합니다. 이 기능을 이용하면 수행하기 전에 작업을 확인할 수 있습니다.

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

이 경우 스크립트를 계속하거나, 변경하거나, 중지할 수 있는 여러 옵션이 있습니다. 도움말 프롬프트는 다음과 같은 각 옵션을 설명합니다.

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

지역화

이 프롬프트는 PowerShell에서 지역화되므로 운영 체제의 언어에 따라 언어가 변경됩니다. PowerShell에서는 사용자를 위해 이 기능도 관리합니다.

`[switch]` 매개 변수

잠시 시간을 내어 매개 변수에 값을 [switch] 전달하는 방법을 살펴보겠습니다. 이를 호출하는 주된 이유는 매개 변수 값을 호출하는 함수에 전달하려는 경우가 많기 때문입니다.

첫 번째 방법은 모든 매개 변수에 사용할 수 있는 특정 매개 변수 구문이지만 대부분 매개 변수에 [switch] 사용되는 것을 볼 수 있습니다. 매개 변수에 값을 연결할 콜론을 지정합니다.

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

변수를 사용하여 동일한 작업을 수행할 수 있습니다.

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

두 번째 방법은 해시 테이블을 사용하여 값을 스플랫하는 것입니다.

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

해시 테이블이나 스플래팅을 처음 접하는 경우, 해시 테이블에 대해 알고 싶은 모든 것을 다룬 또 다른 문서가 있습니다.

SupportsShouldProcess

-WhatIf 및 -Confirm 지원을 활성화하는 첫 번째 단계는 함수의 CmdletBinding에서 SupportsShouldProcess을(를) 지정하는 것입니다.

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

이러한 방식으로 SupportsShouldProcess를 지정하면, 이제 -WhatIf (또는 -Confirm)로 함수를 호출할 수 있습니다.

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

라는 -WhatIf매개 변수를 만들지 않았습니다. SupportsShouldProcess를 지정하면 자동으로 생성됩니다. Test-ShouldProcess에서 매개 변수 -WhatIf를 지정하면 일부 항목이 -WhatIf 처리를 수행하기도 합니다.

참고 사항

사용하는 SupportsShouldProcess경우 PowerShell은 함수에 변수를 $WhatIf 추가하지 않습니다. ShouldProcess() 메서드가 해당 값을 처리하므로 $WhatIf의 값을 확인할 필요가 없습니다.

신뢰하지만 확인

여기에 당신이 부르는 모든 것이 값을 상속한다는 것을 신뢰하는 몇 가지 위험이 있습니다 -WhatIf . 나머지 예제에서는 문제 해결이 되지 않는다고 가정하고, 다른 명령을 호출할 때 매우 명확히 설명하겠습니다. 나는 당신이 같은 작업을 수행하는 것이 좋습니다.

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

당신이 모든 요소들을 충분히 이해하게 된 후, 나중에 그 미묘한 차이들을 다시 다루겠습니다.

$PSCmdlet.ShouldProcess

SupportsShouldProcess을(를) 구현할 수 있는 메서드는 $PSCmdlet.ShouldProcess입니다. $PSCmdlet.ShouldProcess(...) 호출하여 일부 논리를 처리해야 하는지 확인하고, 나머지는 PowerShell이 자동으로 처리합니다. 예제를 확인해보겠습니다.

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

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

$PSCmdlet.ShouldProcess($file.Name)를 호출하면 -WhatIf(및 -Confirm 매개 변수)를 확인하고 적절하게 처리합니다. -WhatIf은 ShouldProcess로 하여금 변경 사항에 대한 설명을 출력하고 $false을 반환하게 합니다.

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

호출을 사용하여 -Confirm 스크립트를 일시 중지하고 사용자에게 계속할 옵션을 묻는 메시지를 표시합니다. 사용자가 Y을 선택하면 $true을 반환합니다.

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의 놀라운 기능 중 하나는 자세한 출력으로도 사용된다는 것입니다. ShouldProcess를 구현할 때 자주 이 기능을 사용합니다.

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

오버로드

다양한 매개 변수를 사용하여 메시지를 사용자 지정하는 $PSCmdlet.ShouldProcess용 몇 가지 오버 로드가 존재합니다. 위의 예제에서 첫 번째 항목이 이미 확인되었습니다. 좀 더 자세히 살펴보겠습니다.

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

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

이렇게 하면 함수 이름과 대상(매개 변수 값)이 모두 포함된 출력이 생성됩니다.

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

두 번째 매개 변수를 작업으로 지정하면 메시지 내 함수 이름 대신 작업 값을 사용합니다.

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

다음 옵션은 메시지를 완전히 사용자 지정하기 위해 세 개의 매개 변수를 지정하는 것입니다. 세 개의 매개 변수를 사용하는 경우 첫 번째 매개 변수는 전체 메시지입니다. 두 번째 매개 변수는 여전히 메시지 출력에 -Confirm 사용됩니다.

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

빠른 매개 변수 참조

사용해야 하는 매개 변수를 파악하기 위해 여기에 온 경우 매개 변수가 다른 -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

나는 두 개의 매개 변수와 함께 하나를 사용하는 경향이있다.

ShouldProcessReason

다른 오버로드보다 고급인 네 번째 오버로드가 있습니다. 이를 통해 ShouldProcess가 실행된 이유를 알 수 있습니다. 나는 단지 완전성을 위해 이것을 여기에 추가하고 있습니다. 대신 $WhatIfPreference가 $true인지 확인할 수 있습니다.

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

$reason 변수를 참조 변수 [ref]로 네 번째 매개 변수에 전달해야 합니다. ShouldProcess은 $reason을(를) None 또는 WhatIf 값으로 채웁니다. 나는 이것이 유용하다고 말하지 않았고 나는 그것을 사용할 이유가 없었다.

배치할 위치

ShouldProcess를 사용하면 스크립트 보안을 강화할 수 있습니다. 따라서 스크립트를 변경할 때 사용합니다. $PSCmdlet.ShouldProcess 호출을 변경 사항과 최대한 가깝게 배치하는 편입니다.

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

항목 컬렉션을 처리하는 경우 각 항목에 대해 호출합니다. 따라서 이 호출은 foreach 루프 안에 놓입니다.

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

ShouldProcess를 변경하는 부분 근처에 배치하는 이유는 -WhatIf가 지정되면 최대한 많은 코드를 실행하고 싶기 때문입니다. 사용자가 이러한 오류를 볼 수 있도록 가능하면 설정 및 유효성 검사를 실행하려고 합니다.

또한 내 프로젝트의 유효성을 검사하는 Pester 테스트에서 이를 사용하는 것을 좋아합니다. 나는 Pester에서 모킹하기 어려운 논리가 있는 경우, 자주 그것을 ShouldProcess로 감싸고 내 테스트에서 -WhatIf로 호출할 수 있습니다. 코드 중 일부를 테스트하는 것이 그 어떤 코드보다도 좋습니다.

$WhatIfPreference

첫 번째 기본 설정 변수는 .입니다 $WhatIfPreference. 기본적으로 이 값입니다 $false . 설정 $true 하면 함수가 지정한 -WhatIf것처럼 실행됩니다. 세션에서 이 설정을 지정하면 모든 명령이 -WhatIf을(를) 실행합니다.

함수를 -WhatIf 로 호출할 때, $WhatIfPreference의 값이 함수 범위 안에서 $true로 설정됩니다.

ConfirmImpact

대부분의 예제는 -WhatIf이지만, 지금까지의 모든 내용은 -Confirm와 함께 사용자에게 메시지를 표시하는 데에도 작동합니다. 함수의 ConfirmImpact을(를) 높음으로 설정하면, 마치 -Confirm으로 호출된 것처럼 사용자에게 메시지를 표시합니다.

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

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

Test-ShouldProcess 호출은 High 영향 때문에 -Confirm 작업을 수행합니다.

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

하지만 사용자에게 메시지를 표시하지 않으면 다른 스크립트에서 사용하기 어렵다는 문제가 발생합니다. 이 경우 $false를 -Confirm으로 전달하여 메시지를 억제할 수 있습니다.

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

이후 섹션에서 지원을 추가하는 -Force 방법을 설명합니다.

$ConfirmPreference

$ConfirmPreference 는 실행을 확인하라는 메시지가 표시되면 ConfirmImpact 제어하는 자동 변수입니다. 여기에는 $ConfirmPreference와 ConfirmImpact 모두에 대한 가능한 값이 나와 있습니다.

High
Medium
Low
None

이러한 값을 사용하면 각 함수에 대해 다양한 수준의 영향을 지정할 수 있습니다. $ConfirmPreference이(가) ConfirmImpact보다 높은 값으로 설정된 경우, 실행을 확인하라는 메시지가 표시되지 않습니다.

기본적으로 $ConfirmPreference가 High로 설정되며 ConfirmImpact는 Medium로 설정됩니다. 함수에서 사용자에게 메시지를 자동으로 표시되게 하려면 ConfirmImpact를 High로 설정하면 됩니다. 그렇지 않으면 파괴적인 경우 Medium로 설정하고, 명령이 프로덕션 환경에서 항상 안전하게 실행될 수 있는 경우에는 Low을 사용하십시오. none로 설정하면, -Confirm를 지정했더라도 메시지가 표시되지 않습니다. (여전히 -WhatIf 지원은 제공됩니다.)

함수를 호출할 때 -Confirm의 값은 $ConfirmPreference 함수의 범위 내에서 Low로 설정됩니다.

중첩된 확인 프롬프트 표시 안 함

호출하는 함수에 의해 $ConfirmPreference가 사용할 수 있습니다. 이렇게 하면 확인 프롬프트를 추가하고 호출하는 함수도 사용자에게 프롬프트를 표시하는 시나리오를 만들 수 있습니다.

메시지 표시를 이미 처리했을 때 호출하는 명령에 -Confirm:$false를 지정하곤 합니다.

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

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

이전에 했던 경고로 다시 돌아가자면, -WhatIf가 함수에 전달되지 않는 경우와 -Confirm가 함수에 전달되는 경우에는 미묘한 차이가 있습니다. 여기에 대해서는 나중에 다시 살펴보겠습니다.

$PSCmdlet.ShouldContinue

ShouldProcess가 제공하는 것보다 더 많은 제어가 필요한 경우, ShouldContinue를 사용하여 프롬프트를 직접 트리거할 수 있습니다. ShouldContinue는 실행할 때마다 메시지를 표시하기 때문에 $ConfirmPreference, ConfirmImpact, -Confirm, $WhatIfPreference, -WhatIf는 무시됩니다.

얼핏 보면, ShouldProcess와 ShouldContinue를 쉽게 혼동할 수 있습니다. 저는 ShouldProcess를 사용해야 한다는 걸 잊지 않는 경향이 있습니다. 그것은 매개 변수가 CmdletBinding에서 SupportsShouldProcess로 불리기 때문입니다. 거의 모든 시나리오에서 ShouldProcess를 사용해야 합니다. 그래서 먼저 그 방법을 다루었습니다.

실제로 작동하는 ShouldContinue를 살펴보겠습니다.

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

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

이렇게 하면 더 적은 수의 옵션으로 더 간단한 프롬프트가 제공됩니다.

Test-ShouldContinue

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

가장 큰 문제는 ShouldContinue 항상 사용자에게 메시지를 표시하기 때문에 사용자가 대화형으로 실행해야 한다는 것입니다. 항상 다른 스크립트에서 사용할 수 있는 도구를 빌드해야 합니다. 이 작업을 수행하는 방법은 .를 구현하는 것입니다 -Force. 이 방법은 나중에 다시 살펴보겠습니다.

모두 예

자동으로 ShouldProcess가 처리되지만 ShouldContinue에 대해서는 좀 더 작업이 필요합니다. 논리를 제어하기 위해 참조로 몇 가지 값을 전달해야 하는 두 번째 메서드 오버로드가 있습니다.

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

루프와 컬렉션을 추가하여 foreach이/가 어떻게 작동하는지 보여주었습니다. 쉽게 읽을 수 있도록 ShouldContinue 문에서 if 호출을 가져왔습니다. 네 가지 매개 변수로 메서드를 호출하면 읽기가 어려워지기 시작하지만 최대한 깔끔하게 표시하고자 노력했습니다.

-Force를 구현하기

ShouldProcess 및 ShouldContinue는 -Force을(를) 서로 다른 방식으로 구현해야 합니다. 이러한 구현의 비결은 ShouldProcess 항상 실행되어야 하지만 ShouldContinue 지정된 경우 -Force 실행해서는 안 된다는 것입니다.

ShouldProcess -Force

당신이 ConfirmImpact을 high로 설정하면, 사용자가 가장 먼저 시도할 것은 -Force을 사용하여 그것을 억제하는 것입니다. 그건 내가 어쨌든 할 첫 번째 일이다.

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

ConfirmImpact 섹션에서 기억하신다면, 실제로 다음과 같이 호출해야 합니다.

Test-ShouldProcess -Confirm:$false

모두가 그것을 해야 한다고 깨닫는 것은 아닙니다. 또한 ShouldContinue를 억제하지 않습니다. 따라서 사용자가 제대로 사용할 수 있도록 -Force를 구현해야 합니다. 다음 전체 예제를 살펴보세요.

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

자체 -Force 스위치를 매개 변수로 추가합니다. CmdletBinding에서 SupportsShouldProcess를 사용할 때 -Confirm 매개 변수가 자동으로 추가됩니다. 그러나 사용하는 SupportsShouldProcess경우 PowerShell은 함수에 $Confirm 변수를 추가하지 않습니다. Strict 모드에서 실행 중이고 변수가 $Confirm 정의되기 전에 사용하려고 하면 오류가 발생합니다. 오류를 방지하려면 사용자가 매개 변수를 전달했는지 테스트하는 데 사용할 $PSBoundParameters 수 있습니다.

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

사용자가 -Force을(를) 지정하면, 로컬 범위에서 $ConfirmPreference을(를) None로 설정합니다. 사용자가 -Confirm도 지정하면, ShoudProcess()은 -Confirm 매개 변수의 값을 따릅니다.

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

누군가 둘 다 -Force와 -WhatIf를 지정하면, -WhatIf가 우선순위를 가져야 합니다. 이 방법은 항상 실행되므로 처리를 -WhatIf 유지합니다ShouldProcess.

$Force 값에 if 문에서 ShouldProcess을(를) 사용하여 테스트를 추가하지 마세요. 이는 다음 섹션에서 보여 주는 내용임에도 불구하고 이 특정 시나리오에 대한 ShouldContinue안티패턴입니다.

ShouldContinue -Force

이것은 -Force를 사용하여 ShouldContinue를 구현하는 올바른 방법입니다.

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

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

연산자의 $Force 왼쪽 -or 에 배치하면 먼저 계산됩니다. 이 방법으로 작성하면 if 구문의 실행이 단락됩니다. $Force이(가) $true인 경우, ShouldContinue은(는) 실행되지 않습니다.

PS> Test-ShouldContinue -Force
Some Action

이 시나리오에서는 ShouldContinue에서 지원되지 않으므로 -Confirm나 -WhatIf를 걱정할 필요가 없습니다. 이 때문에 ShouldProcess와 다르게 처리해야 합니다.

범위 문제

함수 내의 모든 항목과 함수가 호출하는 모든 항목에 -WhatIf와 -Confirm를 적용해야 합니다. 이를 위해 함수의 로컬 범위에서 $WhatIfPreference을 $true로 설정하거나 $ConfirmPreference를 Low로 설정합니다. 다른 함수를 호출할 때, ShouldProcess은(는) 해당 값을 사용하여 호출됩니다.

실제로 대부분의 경우에 올바르게 작동합니다. 기본 제공 cmdlet 또는 동일한 범위의 함수를 호출할 때마다 작동합니다. 콘솔에서 스크립트 모듈에서 스크립트 또는 함수를 호출할 때도 작동합니다.

제대로 작동하지 않는 경우는 스크립트 또는 스크립트 모듈이 다른 스크립트 모듈에서 함수를 호출할 때입니다. 이것은 큰 문제처럼 들리지 않을 수 있지만 PSGallery에서 만들거나 가져오는 대부분의 모듈은 스크립트 모듈입니다.

핵심 문제는 스크립트 모듈이 다른 스크립트 모듈의 함수에서 호출될 때, $WhatIfPreference, $ConfirmPreference 및 기타 몇 가지 값을 상속하지 않는다는 것입니다.

이를 일반적인 규칙으로 요약하는 가장 좋은 방법은 이진 모듈에서는 제대로 작동하지만, 스크립트 모듈에서는 절대 작동한다고 믿지 말라는 것입니다. 확신이 없다면, 테스트를 해보거나 제대로 작동하지 않을 것이라고 가정하십시오.

개인적으로 이것이 대단히 위험하다고 생각하는데, 고립된 상태에서는 정상적으로 작동하지만 서로 호출하면 정상적으로 작동하지 못하는 여러 모듈에 -WhatIf 지원을 추가하는 상황이 발생하기 때문입니다.

이 문제를 해결하기 위해 GitHub RFC가 작동합니다. 자세한 내용은 스크립트 모듈 범위를 넘어선 실행 기본 설정 전파를 참조하세요.

마무리하며

사용해야 할 때마다 ShouldProcess 사용 방법을 확인합니다. ShouldProcess와 ShouldContinue를 구별하는 데 오랜 시간이 걸렸습니다. 나는 거의 항상 사용할 매개 변수를 조회해야합니다. 그러니 혼란스러울 때가 있더라도 걱정할 필요가 없습니다. 이 문서는 필요할 때 여기에 있습니다. 저도 자주 참조하겠습니다.

이 게시물을 좋아했다면 아래 링크를 사용하여 트위터에서 나와 의견을 공유하십시오. 저는 항상 내 콘텐츠에서 가치를 얻는 사람들의 말을 듣는 것을 좋아합니다.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-04-08