Bash 在shell脚本中使用具有完整路径名的二进制文件是否被认为是一种良好的做法？

我想以一种被认为是良好实践的方式编写shell脚本

---

一位经验丰富的程序员朋友建议对每个外部命令使用完整路径名，以避免别名、函数等问题，避免与现有二进制文件使用相同的名称，甚至可能是出于恶意原因。我理解这个论点，但是短命令（在$PATH中）很快就会变长，比如：

sudo socketfilterfw --setloggingmode on

变成

/usr/bin/sudo /usr/libexec/ApplicationFirewall/socketfilterfw --setloggingmode on

这让我很难快速掌握脚本的功能。但也许我只是需要习惯这一点。 查看github上的脚本示例，我确实发现有人也这么做，但大多数人都没有

---

使用二进制文件的完整路径是否被视为“良好做法”？

否，一般建议的做法是依靠路径的正确性；或者，有时，如果您知道一个程序的预期位置，而该位置通常不在

路径

上，则可以扩展

路径

PATH="$PATH:/usr/libexec/ApplicationFirewall"

sudo socketfilterfw --setloggingmode on

将路径硬编码为二进制意味着您无法轻松地将其替换为用于本地管理或调试的自定义包装器；这只会让每个人的生活更艰难

---

另一方面，一个常见的（但无害的）错误是不必要地导出路径。除非需要脚本的子进程来继承变量，否则无需导出它。（在实践中，您通常可以确信用户已经在登录shell中这样做了；虽然对于不总是从交互shell运行的系统进程，这不一定是给定的）。

避免别名、函数等问题。因为它依赖于位于特定位置的二进制文件，所以脚本的可移植性较差。别名在非交互式脚本中被默认禁用。我也会认为这是一个错误的做法。它使脚本忽略我的系统配置，例如使用

/usr/local/bin

或

~/bin

中的工具，或者通过设置路径来覆盖Java等平台的版本。我认为人们有时把它误认为是一个好的实践的原因是因为它隐藏了配置问题，如果它使脚本在某些情况下工作，他们会认为这一定是一件好事。谢谢！这正是我所经历的：不同风格的linux和macOS在/sbin/、/usr/local/sbin/等中都有二进制文件。我必须添加检查和解决方法（比如通过“command-v blah”查找每个命令），以使脚本再次工作。