PowerShell Completion should not impact global namespace

[jfishe]

chezmoi PowerShell Completion missing Native parameter #5133 uses cobra to generate PowerShell completion.
Cobra exposes a function and filter to PowerShell global namespace.
This should be avoided because it prevents lazy loading of shell completion and
could create name collision.

Recommend moving the globals inside the completion [scriptblock].

#2437 is a related issue with the Native parameter.

Describe the bug

chezmoi completion powershell produces:

# powershell completion for chezmoi                              -*- shell-script -*-

function __chezmoi_debug {
    if ($env:BASH_COMP_DEBUG_FILE) {
        "$args" | Out-File -Append -FilePath "$env:BASH_COMP_DEBUG_FILE"
    }
}

filter __chezmoi_escapeStringWithSpecialChars {
    $_ -replace '\s|#|@|\$|;|,|''|\{|\}|\(|\)|"|`|\||<|>|&','`$&'
}

[scriptblock]${__chezmoiCompleterBlock} = {
    param(
            $WordToComplete,
            $CommandAst,
            $CursorPosition
        )

<snip>

}

Register-ArgumentCompleter -CommandName 'chezmoi' -ScriptBlock ${__chezmoiCompleterBlock}

## To reproduce

```powershell
pwsh --noprofile
chezmoi completion powershell

Expected behavior

# powershell completion for chezmoi                              -*- shell-script -*-

[scriptblock]${__chezmoiCompleterBlock} = {
    param(
            $WordToComplete,
            $CommandAst,
            $CursorPosition
        )

    function __chezmoi_debug {
        if ($env:BASH_COMP_DEBUG_FILE) {
            "$args" | Out-File -Append -FilePath "$env:BASH_COMP_DEBUG_FILE"
        }
    }

    filter __chezmoi_escapeStringWithSpecialChars {
        $_ -replace '\s|#|@|\$|;|,|''|\{|\}|\(|\)|"|`|\||<|>|&','`$&'
    }

<snip>
}

Register-ArgumentCompleter -CommandName 'chezmoi' -ScriptBlock ${__chezmoiCompleterBlock}

[Explaimaus-Hash]

Digging into a scoping bug in Cobra's PowerShell completions

While looking through open issues on [spf13/cobra](https://github.com/spf13/cobra) (the CLI framework behind a huge chunk of the Go ecosystem — kubectl, hugo, etc. all use it), I came across [#2438](#2438), a bug about PowerShell tab-completion leaking stuff into the global shell namespace. Someone had already opened a PR for it by the time I got to it, so this didn't end up merged anywhere — but I worked through the whole thing anyway because it turned out to be a genuinely interesting bug once I understood what was going on.

What's actually happening

Cobra can auto-generate a completion script for whatever shell you use — bash, zsh, fish, PowerShell. For PowerShell specifically, the generated script is supposed to be lazy: nothing should actually run or get defined until you hit Tab. But the reporter noticed that when you source the completion file, a couple of functions show up in your shell immediately — __<yourcli>_debug and __<yourcli>_escapeStringWithSpecialChars — even though you haven't typed anything yet.

Turns out this is a PowerShell scoping thing, not a Go bug. If you define a function outside of a [scriptblock]{ }, PowerShell treats it as a normal top-level definition and shoves it straight into the global scope the second the file loads. If it's inside the scriptblock, it only exists when that block actually runs — which for a completer is only when you press Tab. So the whole fix comes down to: those two function/filter definitions were sitting one level too high in the generated script.

Finding it in the code

The script itself isn't written as a .ps1 file anywhere in the repo — it's built as one long Go string inside genPowerShellComp() in powershell_completions.go, using fmt.Sprintf. So "the bug" is really just where two chunks of text sit relative to a { in that string. Once I found the function and actually read through the template, it was pretty obvious — the function and filter blocks were written before [scriptblock]${...CompleterBlock} = { opens, instead of after param(...) closes inside it.

The fix itself

Cut both blocks out from where they were, pasted them back in right after param(...), re-indented so it reads cleanly, and left everything else alone. Nothing about what the functions do changed — just where they live in the generated output.

Making sure it actually worked

I didn't want to just trust that it compiled. go build and the existing test suite both passing doesn't tell you the actual bug is gone — there wasn't even a test that checked this specific thing. So I wrote a quick throwaway test that calls GenPowerShellCompletion directly, dumped the output to a file, and read it:

[scriptblock]${__myappCompleterBlock} = {
    param(
        $WordToComplete,
        $CommandAst,
        $CursorPosition
    )
    function __myapp_debug {
        ...
    }
    filter __myapp_escapeStringWithSpecialChars {
        ...
    }
    ...

Both helpers now sit inside the braces, right where they should. That's the actual proof — not the green checkmark from go test.

Takeaways

The thing that stuck with me most is how small this bug was in terms of lines changed, but how much you had to actually understand to know it was even a bug — PowerShell scoping rules, not Go. It's a good reminder that "the code compiles and tests pass" and "the bug is fixed" are two different claims, and only one of them is actually worth trusting.

Also — checking whether an issue already has a linked PR before diving in saved me from wasting effort on a duplicate. Small thing, but worth doing first every time.