在类似的管道中
GenerateLotsOfText | external-program | ConsumeExternalProgramOutput
当外部程序退出时，管道将继续运行，直到GenerateLotsOfText完成。假设外部程序仅生成一行输出，则
GenerateLotsOfText | external-program | Select-Object -First 1 | ConsumeExternalProgramOutput
将从外部程序生成输出的那一刻起停止整个管道。这是我正在寻找的行为，但需要注意的是，当外部程序不生成输出但提前退出时（例如由于 ctrl-c），管道仍然继续运行。因此，我现在正在寻找一种好方法来检测何时发生这种情况，并在发生这种情况时终止管道。
似乎可以编写一个使用
System.Diagnostics.ProcessRegister-ObjectEvent我认为几乎所有其他 shell 都通过
||&&GenerateLotsOfText | cmd /c '(external-program && echo FOO) || echo FOO' | Select-Object -First 1 | FilterOutFooString | ConsumeExternalProgramOutput
因此，无论外部程序做什么，当它退出时总会产生一行 FOO，因此管道将立即停止（然后 FilterOutFooString 只负责产生实际输出）。这不是特别“好”，并且有额外的开销，因为一切都需要通过 cmd 进行管道传输（或者我认为任何其他 shell 也可以工作）。我希望 管道链运算符 本身允许这样做，但他们似乎不允许：尝试相同的语法会导致
Expressions are only allowed as the first element of a pipeline.GenerateLotsOfText | ((external-program && echo FOO) || echo FOO) | Select-Object -First 1
还有其他方法可以实现这一点吗？
更新其他可能的方法：
$LASTEXITCODE$otherRunspace.SessionStateProxy.GetVariable('LASTEXITCODE')NativeCommandProcessorExecutionFailed$LASTEXITCODE在实现了最后一个非常简单的想法之后对此进行了研究，以上都不是一个选项：进程退出代码基本上只有在管道的
end需要明确的是：正如最初针对 Unix 以及随后针对 Windows 所报告的那样，PowerShell 的当前行为（从 v7.4.x 开始）应被视为一个 bug，有望得到修复：PowerShell 应检测何时本机（外部程序）已退出，应停止该事件中的所有上游命令。
以下显示了通用解决方法，但是，它总是减慢速度并且有限制：
Select-Object -First定义函数
nw在 Windows 上（假定 WSL；省略
-Verbose1..1e8 | nw wsl head -n 10 -Verbose
在类 Unix 平台上（省略
-Verbose1..1e8 | nw head -n 10 -Verbose
您将看到上游命令（大型输入数组的枚举）在
head实施说明：
nwfunction nw {
[CmdletBinding(PositionalBinding = $false)]
param(
[Parameter(Mandatory, ValueFromRemainingArguments)]
[string[]] $ExeAndArgs
,
[Parameter(ValueFromPipeline)]
$InputObject
)
begin {
# Split the arguments into executable name and its arguments.
$exe, $exeArgs = $ExeAndArgs
# Determine the process name matching the executable.
$exeProcessName = [IO.Path]::GetFileNameWithoutExtension($exe)
# The script block to use with the steppable pipeline.
# Simply invoke the external program, and PowerShell will pipe input
# to it when `.Process($_)` is called on the steppable pipeline in the `process` block,
# including automatic formatting (implicit Out-String -Stream) for non-string input objects.
# Also, $LASTEXITCODE is set as usual.
$scriptCmd = { & $exe $exeArgs }
# Create the steppable pipeline.
try {
$steppablePipeline = $scriptCmd.GetSteppablePipeline($myInvocation.CommandOrigin)
# Record the time just before the external process is created.
$beforeProcessCreation = [datetime]::Now
# Start the pipeline, which creates the process for the external program
# (launches it) - but note that when this call returns the
# the process is *not* guaranteed to exist yet.
$steppablePipeline.Begin($PSCmdlet)
}
catch {
throw # Launching the external program failed.
}
# Get a reference to the newly launched process by its name and start time.
# Note: This isn't foolproof, but probably good enough in practice.
# Ideally, we'd also filter by having the current process as the parent process,
# but that would require extra effort (a Get-CimInstance call on Windows, a `ps` call on Unix)
$i = 0
while (-not ($ps = (Get-Process -ErrorAction Ignore $exeProcessName | Where-Object StartTime -GT $beforeProcessCreation | Select-Object -First 1))) {
if (++$i -eq 61) { throw "A (new) process named '$exeProcessName' unexpectedly did not appear with in the timeout period or exited right away." }
Start-Sleep -Milliseconds 50
}
}
process {
# Check if the process has exited prematurely.
if ($ps.HasExited) {
# Note: $ps.ExitCode isn't available yet (even $ps.WaitForExit() wouldn't help),
# so we cannot use it in the verbose message.
# However, $LASTEXITCODE should be set correctly afterwards.
Write-Verbose "Process '$exeProcessName' has exited prematurely; terminating upstream commands (performance penalty on first call in a session)..."
$steppablePipeline.End()
# Throw the private exception that stops the upstream pipeline
# !! Even though the exception type can be obtained and instantiated in
# !! PowerShell code as follows:
# !! [System.Activator]::CreateInstance([psobject].assembly.GetType('System.Management.Automation.StopUpstreamCommandsException'), $PSCmdlet)
# !! it cannot be *thrown* in a manner that *doesn't*
# !! result in a *PowerShell error*. Hence, unfortunately, ad-hoc compilation
# !! of C# code is required, which incurs a performance penalty on first call in a given session.
(Add-Type -PassThru -TypeDefinition '
using System.Management.Automation;
namespace net.same2u.PowerShell {
public static class CustomPipelineStopper {
public static void Stop(Cmdlet cmdlet) {
throw (System.Exception) System.Activator.CreateInstance(typeof(Cmdlet).Assembly.GetType("System.Management.Automation.StopUpstreamCommandsException"), cmdlet);
}
}
}')::Stop($PSCmdlet)
}
# Pass the current pipeline input object to the target process
# via the steppable pipeline.
$steppablePipeline.Process($_)
}
end {
$steppablePipeline.End()
}
}