Shell 脚本通常必须依赖于用户计算机上可能未安装的工具。为了避免这个问题，许多脚本都有多种后备措施。
在我看来，这样做只会导致代码变得复杂，并且发现大量脚本仅用于兼容性原因的情况并不少见。
为什么不能将依赖项包含在脚本中？该脚本可以包含这些程序（作为附加的压缩部分，就像makeself那样），并在运行时简单地使用它们？
澄清一下，这当然不适用于wget和 之类的东西curl；在这种情况下，每个的代码都是最少的。我说的是涉及 GUI 的脚本，并且有很多代码来支持此类程序（zenity/ yad/xdialog等），其中涉及截然不同的语法。
上面的事情没有完成还有什么原因吗？
答案1
上面的事情没有完成还有什么原因吗？
Shell 脚本是可移植的，因为它们使用运行时解释器。您用作示例的工具（特别是 GUI 工具）不是。这意味着您必须有一个适用于 Linux/x86、Linux/x86-64、Linux/armel、Linux/armhf、OSX/x86-64、OpenBSD/mipsel 以及您希望在其上运行的任何其他平台的单独版本。
此外，这些东西的正常编译版本依赖于共享库。如果您确实不想担心依赖项，但又想包含SomeGUIApp，则需要它的静态编译版本，或者 (6 == 2 * 3) 来包含这些依赖项及其依赖项，并且... 1 无论哪种方式，此时您都会意识到您认为的“只有 5 mb”最终会变成数百。看看你现在的内存消耗情况；如果它是一个执行正常操作的普通 GUI 桌面，那么其中大部分就是那些 GUI 库等。
作为一个长期的 Linux 用户，我通常对包含二进制文件的东西感到遗憾，因为通用编译的东西可能会犯很多错误。只有在没有其他选择的情况下我才会真正使用它们（或者，当然，它们来自发行版）。
现在想象一下，如果每个人都这样做。SomeGUIApp我的系统上需要 15 个副本吗？最好将一些东西列为先决条件 - 如果我没有它，我可以获得它 - 为我提供我已经拥有的东西的另一个副本。
1. 也许要点是：你必须在某个地方划清界限，那么为什么不把它划在包装上原来的地方呢？