主页 / unix / 问题 / 766030
Accepted
Marcus
Asked: 2024-01-03 19:18:10 +0800 CST

通过命令替换处理“systemctl status”的原因？

  • 772

在脚本中，我发现了一种处理systemctl status输出的奇怪方法：

echo "$(systemctl status the_unit_name)" | grep -q 'Active: active'

而不是显而易见的：

systemctl status the_unit_name | grep -q 'Active: active'

我找不到使用这种方法的任何有效理由。我失踪有什么原因吗？

bash

2 个回答

  1. Best Answer

    systemctl除了可能忽略 的退出状态（这取决于周围的设置）之外，没有任何原因。可能有历史因素解释为什么命令是这样写的，但没有理由保持这种方式。

    另请参阅测试服务是否在脚本中运行的“正确”方法。

    • 10

  2. 一般来说，echo "$(foo)"是愚蠢的并且几乎等同于 just foo。区别在于，命令替换会从 的输出中删除所有尾随换行符foo，并echo恰好添加一个（并且可能会处理反斜杠，但我们假设它不会）。通常，这不会改变任何东西，因为输出最终很可能恰好是一个。

    但是，如果 的输出foo缺少最后的换行符，则确实意味着echo和 命令替换的组合可以修复该问题，确保管道的右侧获得正确的文本文件作为输入。这在原则上很重要，因为从技术上讲，POSIX 标准要求输入必须是正确的文本文件，如果不是，显然可能会出现意外行为。

    在实践中，我从未见过grep这样的实现在技术上无效的输入上出现问题，或者以与其他行不同的方式处理最终的无换行符行片段。考虑到 grep 的工作原理，基本上忽略换行符，不明显的行为很容易发生。（此外，fgets()用于读取行的 C 标准函数也并不真正关心末尾是否有换行符，这与 shell 的 不同read，其中退出状态取决于是否看到换行符。然后再说一遍，如果实用程序不检查它所读取的内容，则假设末尾必须有一个换行符，并无条件地删除最后一个字符，例如buf[strlen(buf) - 1] = '\0'，如果最后一个换行符丢失，那么这将吃掉最后一个常规字符。）

    也就是说，我也不相信这实际上是他们执行那个看起来奇怪的命令的原因。（而且我认为不会systemctl产生不正确的输出。）更有可能的是，他们只是没有真正思考自己在做什么。

    • 6

相关问题