shell -/bin/sh : Odd string comparison error 'unexpected operator'

Question

这个问题在这里已经有了答案:





Unexpected operator error [duplicate]

(4 个回答)


5年前关闭。




发现这个错误很奇怪，因为以前我的脚本可以工作，但是在我将它从我正在处理的服务器移到我的本地机器后，它停止工作，只是给了我一个“意外的运算符(operator)”错误。

# Else if the script is being run in the arrayscripts directory, add /output/ ...
elif [ $basePath == "arrayscripts" ];
then
        echo "$dscr has started to run."
        cpuPath="`pwd`/output/cpu.binary"
        txtPath="`pwd`/output/cpu.txt"
        csvPath="`pwd`/output/cpu.csv"

Answer 1

如果您的实际 shell 是 /bin/sh [与最初的问题相反，但正如讨论评论所阐明的那样]，使用 =而不是 ==在您的测试表达式中:

elif [ "$basePath" = arrayscripts ]

请注意，在这种情况下不需要引用右侧，因为它不包含扩展和语法敏感字符。

或者，如果此问题在使用 bash 时可重现，则明显的问题是缺少引号。

使用任一

[ "$basePath" = arrayscripts ] # this is POSIX compatible

或者

[[ $basePath = arrayscripts ]] # this works only with bash

否则，参数数量 $basePath扩展为未定义——它可能扩展为零个参数，使语句

[ = arrayscripts ]

...这将尝试使用 =作为一元运算符，它不是......

或者如果 $basePath包含，比如说， "true -o bar =" ，它可以扩展成类似的东西

[ true -o bar = arrayscripts ]

...导致程序行为与您实际想要的非常不同。

底线:在编写遵循 POSIX 规则的 shell 时(基本上，除了 zsh 或fish 之外的任何东西)，除非您有特定且令人信服的理由不这样做，否则请引用您的扩展。 (使用 bash/ksh 扩展 [[ ]] 提供了这样一个原因，通过引入一个上下文，在该上下文中不会发生扩展结果的字符串拆分和全局扩展)。