Поддержка параметров ScriptBlock лексической области (например, Where-Object)

Приведенный пример не работает, потому что вызов функции по умолчанию войдет в новую область. Where-Object по-прежнему будет вызывать сценарий фильтра, не вводя его, но область действия функции не имеет переменной private.

Есть три способа обойти это.

Поместите функцию в другой модуль, чем вызывающий

Каждый модуль имеет SessionState, у которого есть собственный стек SessionStateScope. Каждый ScriptBlock привязан к SessionState, который был проанализирован.

Если вы вызываете функцию, определенную в модуле, новая область создается внутри SessionState этого модуля, но не на верхнем уровне SessionState. Поэтому, когда Where-Object вызывает скрипт фильтра без входа в новую область, он делает это в текущей области для SessionState, к которой привязан этот ScriptBlock.

Это немного хрупко, потому что если вы хотите вызвать эту функцию из своего модуля, вы не сможете это сделать. Будет такая же проблема.

Вызовите функцию с точечным оператором источника

Скорее всего, вы уже знаете оператор точки-источника (.) для вызова файлов сценариев без создания новой области. Это также работает с именами команд и ScriptBlock объектами.

. { 'same scope' }
. Foo-MyBar

Обратите внимание, однако, что это вызовет функцию в текущей области SessionState, из которой эта функция, поэтому вы не можете полагаться на то, что . всегда будет выполняться в текущей области вызывающего сфера. Следовательно, если вы вызываете функции, связанные с другим SessionState, с помощью оператора точки-источника, например, функции, определенные в (другом) модуле, это может привести к непредвиденным последствиям. Созданные переменные будут сохраняться для будущих вызовов функций, и любые вспомогательные функции, определенные внутри самой функции, также будут сохраняться.

Написать командлет

Скомпилированные команды (командлеты) не создают новую область при вызове. Вы также можете использовать API, похожие на то, что использует Where-Object (хотя и не точно такие же).

Вот грубая реализация того, как вы могли бы реализовать Where-Object с помощью общедоступного API.

using System.Management.Automation;

namespace MyModule
{
    [Cmdlet(VerbsLifecycle.Invoke, "FooMyBar")]
    public class InvokeFooMyBarCommand : PSCmdlet
    {
        [Parameter(ValueFromPipeline = true)]
        public PSObject InputObject { get; set; }

        [Parameter(Position = 0)]
        public ScriptBlock FilterScript { get; set; }

        protected override void ProcessRecord()
        {
            var filterResult = InvokeCommand.InvokeScript(
                useLocalScope: false,
                scriptBlock: FilterScript,
                input: null,
                args: new[] { InputObject });

            if (LanguagePrimitives.IsTrue(filterResult))
            {
                WriteObject(filterResult, enumerateCollection: true);
            }
        }
    }
}

как Where-Object фиксирует значение $private:pattern в тесте 1

Как видно из исходного кода кода для Where-Object в PowerShell Core, PowerShell внутренне вызывает скрипт фильтра, не ограничивая его собственной локальной областью (_script — это закрытое резервное поле для параметра FilterScript, обратите внимание, что аргумент useLocalScope: false передается в DoInvokeReturnAsIs()):

protected override void ProcessRecord()
{
    if (_inputObject == AutomationNull.Value)
        return;

    if (_script != null)
    {
        object result = _script.DoInvokeReturnAsIs(
            useLocalScope: false, // <-- notice this named argument right here
            errorHandlingBehavior: ScriptBlock.ErrorHandlingBehavior.WriteToCurrentErrorPipe,
            dollarUnder: InputObject,
            input: new object[] { _inputObject },
            scriptThis: AutomationNull.Value,
            args: Utils.EmptyArray<object>());

        if (_toBoolSite.Target.Invoke(_toBoolSite, result))
        {
            WriteObject(InputObject);
        }
    }
    // ...
}

как добиться такого же поведения в наших собственных функциях/командлетах?

Мы этого не делаем – DoInvokeReturnAsIs() (и аналогичные средства вызова блоков сценариев) помечены internal и, следовательно, могут вызываться только типами, содержащимися в сборке System.Management.Automation.