☰

if [ -n $diffCurr ] 出错：参数太多

tag-icon • tag-icon diff test
if [ -n $diffCurr ] 出错：参数太多

我使用下面的代码已经有一段时间了，但现在出现错误

java Editor < "input/editor$i.in" > "tmp/editor$i.out"
diffCurr="$(diff "tmp/editor$i.out" "output/editor$i.out")"
if [ -n $diffCurr ]

错误（发生在上面代码片段的最后一行）：

[： 争论太多

怎么了？我正在尝试测试差异结果是否为空（即文件中的内容相同）

答案1

无需将 的输出放入diff变量中，因为您可以根据 的退出状态判断文件是否不同diff，例如

if diff -q file1 file2 >/dev/null 2>&1; then
        # files are equal
else
        # files differ, or an error occurred
fi

diff0如果文件没有差异，则返回 success ( )。根据需要调整逻辑。

在可能的情况下测试命令的退出状态几乎总是优于通过命令替换检查或解析输出。

为了完整起见，您的原始示例发生错误是因为您没有"$diffCurr"在该行中引用if，因此它经过“分词”变成多个单词——因此“参数太多”。

答案2

jw013 是对的，无论如何你都不需要这条线。

但为了回答实际问题，您在传入的变量周围省略了引号test（也称为[）。

这意味着如果您的变量为空，则就像您没有参数（例如[ -n ]），如果您的变量包含空格，则就像您传递了多个参数（我猜这就是发生的情况）。

始终test用引号将字符串括起来，例如：

if [ -n "$myvar" ]

答案3

测试命令的退出代码可能diff比测试输出更好。

diffCurr="$(diff "tmp/editor$i.out" "output/editor$i.out")"
if [ $? -ne 0 ]; then  # different
...

如果您对输出不感兴趣，那么您可以按照 jw013 的建议进行操作。

答案4

除了上面的好答案之外：我对 bash 的爱/恨关系主要集中在它在参数替换方面的优势，事实上，当你想要它时让它停止替换可能非常具有挑战性 - 特别是当使用变量时或多次更改。

因此，我几乎总是对变量引用进行编码，例如：

A="${B}"

这确保B被视为单个字符串（最常见的是我想要的），并且它允许诸如

A="${B}foo"

以及其他一些仅在大括号内起作用的奇特选项。

如果我将一个简单的安全变量引用编码为

A="${B}"

首先，当我稍后返回修改代码时，如果缺少引号或大括号，可能会做一些可能会失败的事情，这样我会安全得多。

相关内容