Shell 脚本 - 使用 bin/echo 而不是 echo 的原因？

Question

我有一个 2011 年的 shell 脚本，目的是在不同的 unix 系统上运行。

脚本定义了一些变量，我不明白背后的逻辑，我想知道为什么要这样做。例如:
而不是直接在脚本中使用 echo 或 grep，这些变量定义如下:
ECHO="/bin/echo"
GREP="/bin/grep"(适用于 Linux)
对于 Solaris 或其他，也定义了相应的路径。然后将它们用作 ${ECHO} “something out”

这种做法的目的是什么，为什么我不能直接使用它？

Answer 1

正如其他人指出的那样，这些行不太可能是正确的，更有可能是:

ECHO="/bin/echo"
GREP="/bin/grep"  # (for linux)

假设它们是正确的，像这样的代码曾经在 shell 脚本中很常见(不是我的，我可能会补充)。您不会再看到很多人使用这些。

echo:ksh(Korn shell，曾经是首选的 shell)，csh(C-shell，默认 shell Sun) 和 sh(POSIX 之前的 Bourne shell)都有自己内置的 echo 版本，它们略有不同(主要围绕 -n参数)。因此，独立程序 /bin/echo 有时用于可移植性。为此要付出性能代价。

grep 等:过去通常建议在脚本中设置外部程序的完整路径名。主要原因是安全。理论上，用户可以在本地目录中提供他们自己的版本并更改他们的 PATH 变量。 PATH 和所有其他环境变量仍然被许多人认为是安全风险。第二个原因是搜索 $PATH 目录的性能开销 - 这是在跟踪别名 (ksh) 或散列 (bash) 出现之前。

我再说一遍，我不同意所有这些观点，多年来我与那些同意的人争论不休，但这就是解释。在我看来，这种做法造成的问题多于解决的问题。

编辑:我提到的做法可以追溯到 1970 年代和 80 年代。为什么他们会出现在 2011 年的剧本中？可能是因为“我们总是这样做”，也就是“公司政策”，即没有人知道或关心为什么，我们只是这样做。或者，它可能是从旧网站或书籍中复制粘贴的情况，或者甚至是认为这是个好主意的人。