windows - 为什么不需要 `call` 从管道中涉及的被调用批处理脚本返回？

Question

假设有一个批处理文件(调用者)执行另一个批处理文件(被调用者)，需要使用call命令，以便在被调用者执行完成后返回给调用者。这是一个例子:

caller.bat:

echo Calling another script...
call callee.bat
echo Returned from callee...

callee.bat(在同一位置):

echo   Being called from caller...

输出将是这样的(省略命令回显)，表明执行按预期返回:

Calling another script...
  Being called from caller...
Returned from callee...

如果 call 命令在调用者中被取消，输出将是:

Calling another script...
  Being called from caller...

---

但是一旦被调用者参与到管道(|)中，是否使用call命令就没有区别了。例如:

caller.bat(被调用者保持不变):

echo Calling another script...
break | callee.bat
echo Returned from callee...

虽然没有 call 命令，但输出将是这样。

Calling another script...
  Being called from caller...
Returned from callee...

这种行为的原因是什么，是什么导致执行返回到这里的调用者？

Answer 1

有两种方法可以从调用方调用另一个批处理文件(主 文件):call callee.bat 和 cmd/C callee.bat;不同之处在于 call 在调用程序的相同上下文中执行另一个批处理文件，因此它们共享相同的环境变量和另一个状态，而 cmd/C 在完全独立的上下文中执行另一个批处理文件。作为个人笔记，我曾经将通过 call 调用的批处理文件命名为 internal subroutine，将通过 调用的批处理文件命名为 external subroutine cmd/C(并且覆盖直接调用的批处理文件，无需call 或cmd/C，继承 调用者批处理文件的行为和上下文)。

在管道的执行中，管道的两边都是通过cmd/C执行的，所以两边都是作为外部子程序调用的。这样，如果管道的任何一侧是 Batch.BAT 文件，它会在结束时返回到调用程序。

相同的行为发生在放置在 for/F 命令中的被调用者批处理文件中，出于同样的原因，exaclty； for/F %%a in ('calle.bat') do ...