0

我正在尝试在 bash 中运行命令（ gerrit query ）并将其分配给变量。我正在使用这是一个 bash 脚本文件，并且我想处理如果命令抛出错误（即如果 gerrit 查询失败）的情况，我应该能够处理相同的情况。

例如：

var=`ssh -p $GERRIT_PORT_NUMBER $GERRIT_SERVER_NAME gerrit query --current-patch-set $PATCHSET_ID`

我知道我可以使用 $? 检查最后的退出状态？在 bash 中，但对于上述情况，对变量的赋值会覆盖早期的退出状态（即 gerrit 查询失败状态），并且上述命令永远不会失败。它总是正确的。

你能告诉我是否有办法处理命令的退出状态，即使它被分配给 bash 中的变量。

更新：
我在这里的假设是错误的，即分配导致退出状态被覆盖，而查尔斯的例子和他的回答中的解释是正确的。退出状态被覆盖的真正原因是我将上述命令的输出传送到 sed 脚本，这是覆盖退出状态的罪魁祸首。我发现以下内容帮助我解决了这个问题。https://unix.stackexchange.com/questions/14270/get-exit-status-of-process-thats-piped-to-another/73180#73180 在 Bash 中管道输出和捕获退出状态

我正在尝试的完整命令。

变量=ssh -p $GERRIT_PORT_NUMBER $GERRIT_SERVER_NAME gerrit query --current-patch-set $PATCHSET_ID | sed 's/message//'

4

1 回答 1

3

这个问题的断言是不真实的；分配不会修改退出状态。您可以自己检查：

var=$(false); echo $?

...将正确发射1.

也就是说，如果在 , 或类似关键字的上下文中完成分配，则local可能declare不再适用：

f() { local var=$(false); echo $?; }; f

...将发出0，并通过local从分配中分离出来来解决：

f() { local var; var=$(false); echo $?; }; f

...正确返回1.

SSH 本身也正确返回退出状态，因为您可以类似地测试自己：

ssh localhost false; echo $?

...正确返回1.

因此，合理的结论是，gerrit它本身未能传达不成功的退出状态。这个错误应该通过gerrit的支持机制来解决，而不是作为一个 bash 问题。

于 2014-10-08T23:25:11.890 回答