“|| exit /b”和“|| exit /b !errorlevel!”之间的区别

Question

我们有一堆.bat构建脚本，它们由最近重构的基于 PowerShell 的 GitLab 运行器调用：

program args
if !errorlevel! neq 0 exit /b !errorlevel!

更简洁：

program args || exit /b

今天我调查了一个构建作业，如果您查看错误日志，它显然失败了，但报告为成功。 经过大量实验后，我发现这种模式并不总是按预期工作：

program args || exit /b

但是当前者没有时，这似乎确实有效：

program args || exit /b !errorlevel!

---

我已经阅读了 SO 问题Windows batch exit option b with or without errorlevel和下面来自https://www.robvanderwoude.com/exit.php的声明，但仍然不能完全解释我观察到的内容。

DOS 联机帮助（HELP EXIT）没有明确说明 /B 参数退出当前脚本实例不一定与退出当前脚本相同。 也就是说，如果脚本位于 CALLed 代码段中，则 EXIT /B 退出 CALL，而不是脚本。

---

这是我用来探索这个的最小批处理文件：

@echo off
setlocal EnableDelayedExpansion
cmd /c "exit 99" || exit /b
:: cmd /c "exit 99" || exit /b !errorlevel!

这就是我调用批处理文件的方式（模拟它是如何被基于 GitLab PowerShell 的运行器调用的）：

& .\test.bat; $LastExitCode

这是 output，具体取决于执行批处理文件中两行中的哪一行：

PS> & .\test.bat; $LastExitCode
0
PS> & .\test.bat; $LastExitCode
99

---

还有另一种获得正确行为的方法，即也使用CALL从 PowerShell 中直接调用批处理文件：

PS> & cmd.exe /c "call .\test.bat"; $LastExitCode
99

虽然我明白这可能是从 PowerShell 调用批处理文件的正确方法，但根据我见过的许多示例，这似乎不是常识。 另外我想知道为什么 PowerShell 如果它是“正确的方式”，为什么不以这种方式调用批处理文件。 最后，我仍然不明白为什么在停止call时，行为会根据我们是否添加!errorlevel!而发生变化。 到exit /b语句。

---

更新：感谢到目前为止的所有讨论，但我觉得它在杂草中迷路了，这可能是我在最初的问题中过于含糊的错。 我认为我真正想要的（如果可能的话）是关于何时（应该）在以下语句中评估errorlevel的明确声明：

program || exit /b

它是否真的像这样提前评估（即在program运行之前）：

program || exit /b %errorlevel%

或者它是懒惰评估的（即当program运行并且内部errorlevel已更新后执行exit时），更类似于此：

program || exit /b !errorlevel!

因此，我并不是真的在猜测之后，遗憾的是，除非这是我们能做的最好的，在这种情况下，知道没有明确的答案或者这是一个错误对我来说是一个可以接受的答案:o)。

Answer 1

解决方法：

• 通过cmd /c "<batch-file>... & exit"调用您的批处理文件，在这种情况下|| exit /b 没有显式退出代码的|| exit /b解决方案按预期工作：

  • cmd /c ".\test.bat & exit"

    • 如果需要，将任何嵌入的"字符转义为`" ，例如围绕批处理文件路径和包含空格的传递 arguments：
      cmd /c ".\test.bat `"quoted argument`" & exit"
    • 或者，如果您不需要 PowerShell 的字符串插值来在调用中嵌入变量值，您可以使用'...'引号，在这种情况下嵌入的"可以按原样使用：
      cmd /c '.\test.bat "quoted argument" & exit'

  • 建议定期使用cmd /c "<batch-file>... & exit"从cmd.exe cmd.exe调用批处理文件，因为即使没有显式exit /b （或exit ）调用的批处理文件也可能会出现意外行为 - 请参阅此回答。

• 或者 - 但前提是您的批处理文件永远不需要从另一个批处理文件调用，控制权应该返回到该批处理文件，并且如果它永远不需要成为cmd /c多命令命令行的一部分，它不是最后一个命令^{[ 1]} - 你可以使用|| exit || exit而不是|| exit /b || exit /b - 这将立即退出正在执行的cmd.exe进程作为一个整体，但退出代码（错误级别）随后也会通过直接调用可靠地报告（至少在<command> || exit语句的上下文中）来自外部cmd.exe ，例如来自 PowerShell 的&.\test.bat （或者，在这个简单的例子中，只是.\test.bat ）。

将setlocal EnableDelayedExpansion与exit /b !ERRORLEVEL!结合使用时也可以工作（除了内部(...) - 见这篇文章） - 由于使用了明确的退出代码 - 它显然更麻烦并且可能有副作用，特别是悄悄地删除! 命令中的字符，例如echo hi! （虽然可以通过将setlocal EnableDelayedExpansion调用放在exit /b调用之前的行上来最大限度地减少该问题，但如果有多个出口点，则需要重复）。

---

cmd.exe的行为在这种情况下是不幸的，但无法避免。

从cmd.exe外部调用批处理文件时：

• exit /b -没有退出代码（错误级别）参数 - 仅按预期设置cmd.exe进程退出代码- 即批处理文件中最近执行的命令的退出代码 -如果您遵循批处理 -使用& exit调用文件，即cmd /c <batch-file>... `& exit

  • 如果没有& exit解决方法，来自批处理文件的无参数exit /b调用会反映在%ERRORLEVEL%变量intra- cmd.exe -session中，但这不会转换为cmd.exe的进程退出代码，然后默认为0 。 ^[1]

  • 使用& exit解决方法，批处理文件内无参数exit /b确实正确设置cmd.exe的退出代码，即使在<command> || exit /b中也是如此 <command> || exit /b语句，在这种情况下<command>的退出代码将按预期中继。

• exit /b <code> ，即显式传递退出代码<code> ，始终有效^[2] ，即不需要& exit解决方法。

• 这种区别是一种模糊的不一致，可以合理地称为错误； Jeb 的有用答案包含演示行为的示例代码（在撰写本文时使用不太全面的cmd /c call...解决方法，但它同样适用于cmd /c "... & exit" ）。

---

^{[1] cmd /c可以传递多条语句执行，最后一条语句决定cmd.exe进程的退出码。 例如， cmd /c "ver & dir nosuch"报告退出代码1 ，因为不存在的文件系统项nosuch导致dir将错误级别设置为1 ，无论前面的命令 ( ver ) 是否成功。 不一致之处在于，对于名为test.bat的批处理文件，它以exit /b而没有显式退出代码参数， cmd /c test.bat始终报告0 ，而cmd /c test.bat `& exit正确报告在批处理文件退出之前执行的最后一条语句的退出代码。}

^{[2] 退出代码可以按字面意义或通过变量指定，但陷阱在于 - 由于cmd.exe的前期变量扩展 - <command> || exit /b %ERRORLEVEL% <command> || exit /b %ERRORLEVEL%没有按预期工作，因为此时%ERRORLEVEL%扩展到该语句之前的错误级别，而不是<command>设置的级别； 这就是为什么在这种情况下需要通过运行setlocal enabledelayedexpansion或使用/V选项调用cmd.exe来延迟扩展的原因： <command> || exit /b !ERRORLEVEL! <command> || exit /b !ERRORLEVEL!}

Answer 2

exit /b和exit /b <code>是有区别的。
正如 mklement0 所述，在使用或不使用CALL调用批处理文件时，差异变得可见

在我的测试中，我使用(call)将错误级别强制设置为 1。

测试1.bat

@echo off
(call)
exit /b

测试2.bat

@echo off
(call)
exit /b %errorlevel%

使用test-all.bat进行测试：

cmd /c "test1.bat" & call echo      Test1 %%errorlevel%%
cmd /c "call test1.bat" & call echo call Test1 %%errorlevel%%
cmd /c "test2.bat" & call echo      Test2 %%errorlevel%%
cmd /c "call test2.bat" & call echo call Test2 %%errorlevel%%

Output：

     Test1 0  
call Test1 1  
     Test2 1  
call Test2 1

要获得始终可靠的错误级别，您应该使用exit /b <code>的显式形式。
在使用构造<command> || exit /b !errorlevel!的情况下<command> || exit /b !errorlevel! 延迟扩展是必要的或形式

<command> || call exit /b %%errorlevel%%

另一种解决方案

<command> || call :exit
...

:exit
(
   (goto) 2>nul
   exit /b
)    

这使用批处理异常处理
Windows批处理是否支持异常处理？

Answer 3

让我们看看三种可能的情况：

cmd /c "exit 99" || exit /b

返回0因为cmd /c "exit 99"正确执行

cmd /c "exit 99" || exit /b !errorlevel!

返回99因为cmd /c "exit 99"将errorlevel设置为 99 并且我们返回执行cmd /c "exit 99"产生的错误级别

cmd /c "exit 99" || exit /b %errorlevel%

回报? - 解析cmd /c "exit 99"行时的错误级别，因为当时评估了 `%errorlevel%。

如果没有设置delayedexpansion ，那么唯一的区别就是!errorlevel! 场景尝试将字符串分配给错误级别，这很可能不会很好地工作。

至于 Powershell - 这是一条人迹罕至的道路上的一个角落案例。 一个没有经过彻底测试的场景，因为设计者希望使用此工具执行.exe s 等。 毫无疑问，即使它被报告，它也不会被修复，因为有一个解决方法，即使它没有很好地暴露。

我认为，这就是“失败到失败”的场景——一种假设能够正常工作的设施，因为很少会满足导致其失败的正确条件。

同样，

echo %%%%b

是模棱两可的。 这是否意味着echo显文字%%b或echo显前缀为元变量b的内容的% ？ （答案：后者）。 不是每天都遇到。 解决歧义的机会有多大——永远吗？ 我们甚至无法在date命令上实现/u以使其以通用格式提供日期，这将解决batch标签上发布的绝大多数面向日期的问题。 至于允许date从某个纪元日期开始交付天数的可能性——我什至懒得建议它，因为尽管邀请了cmd修改的建议，但对所提供的设施绝对没有做任何事情，只是用户界面变化。 离开玩所有 shiny 的东西，而老忠实者则在锁着的文件柜的底部萎靡不振。网络被困在一个废弃的厕所里，门上有一个牌子，上面写着“当心豹子”。

Answer 4

消除不相关的 PowerShell 和 Cmd.exe 调用复杂性，这样我们就可以看到 cmd 解释器是如何工作的：

@setlocal EnableExtensions EnableDelayedExpansion
@set prompt=$G

call :DefaultExit
@echo %ErrorLevel%

call :ExplicitExit
@echo %ErrorLevel%

@rem ErrorLevel is now 2

call :DefaultExit || echo One-liner ErrorLevel==%ErrorLevel%, not zero!
@echo %ErrorLevel%

@rem Reset the errorlevel to zero
call :DefaultExit
@echo %ErrorLevel%

call :ExplicitExit || echo One-liner ErrorLevel==!ErrorLevel!
@echo %ErrorLevel%

@exit /b

:DefaultExit
exit /b

:ExplicitExit
exit /b 2

产量：

> test

>call :DefaultExit

>exit /b
0

>call :ExplicitExit

>exit /b 2
2

>call :DefaultExit   || echo One-liner ErrorLevel==2, not zero!

>exit /b
One-liner ErrorLevel==2, not zero
2

>call :DefaultExit

>exit /b
2

>call :ExplicitExit   || echo One-liner ErrorLevel==!ErrorLevel!

>exit /b 2
One-liner ErrorLevel==2
2

如您所见， exit /b完全等同于exit /b %ErrorLevel% ，这不是您想要的|| 故障执行路径。 您必须调用延迟扩展才能从||的左侧获取结果操作员。

---

我对上述脚本又进行了一次快速测试，并在脚本退出后从控制台 window 交互式地检查了错误级别：

> echo %errorlevel%
2

可以看到，单独exit /b ，返回2 ，这是之前设置的错误级别。 所以我的直觉似乎是正确的。 您肯定需要某种形式的延迟扩展!ErrorLevel! 或%^ErrorLevel% （根据@aschipfl）。

Answer 5

PowerShell 的&运算符在运行批处理文件时在内部调用cmd.exe /C 。 我敢打赌$LastExitCode指的是调用cmd.exe而不是批处理文件。 在此上下文中， call将ErrorLevel从批处理文件传递到cmd.exe 。

同样的问题出现在cmd.exe （根本不涉及 PowerShell），运行.\test.bat & call echo %^ErrorLevel%不会调用cmd.exe /C来运行批处理文件，所以这有效（意思是它总是返回99 ）。 但是， cmd /C.\test.bat & call echo %^ErrorLevel%就像您的 PowerShell 尝试（按原样返回0和批处理文件）和cmd /C call.\test.bat & call echo %^ErrorLevel%一样失败cmd /C call.\test.bat & call echo %^ErrorLevel%成功，因此返回99 。

顺便说一句， call echo %^ErrorLevel%只是让我们不必使用延迟扩展。