目前我正在开发一个更大的 Bash 脚本（这是我的一个开源项目），它开始变得一团糟。我已将逻辑分解为函数，在可以的情况下使用局部变量，并且只声明了少数全局变量。尽管如此，它仍然变得很难维护。
我考虑过将脚本拆分为多个脚本并将它们源到我的主脚本中（类似于其他语言中的导入）。
但我想知道这是否是一个可行的方法。首先，获取多个脚本可能会严重减慢脚本的执行时间，其次，它会使分发变得更加困难。
那么，这是一个好方法吗？其他（开源）项目是否也这样做？
答案1
是的，这是一种常见的做法。例如，在 Unix 的早期，负责引导系统通过引导阶段进行多用户操作的 shell 代码是单个文件/etc/rc.如今，引导过程由许多 shell 脚本控制，按功能分解，公共功能和变量根据需要从中心位置获取。 Linux 发行版、Mac、BSD 都不同程度地采用了这种方法。
答案2
shell 是当时完成这项工作的正确工具吗？作为一名遇到过代码增长问题的开发人员，我可以告诉您，不应考虑重写，而应考虑将各个部分分离成更适合您希望扩展应用程序的规模的内容 - 也许是 python 或 ruby，甚至是 perl ？
Shell 是一种实用程序语言 - 它是一种脚本语言 - 因此很难将其扩展至这样的大小。
答案3
如果它使您的维护更容易，您可以两者兼而有之。将其分成逻辑部分，以便您可以轻松维护它，然后编写（例如）一个 Makefile 将其全部重新组合在一起以进行分发您可以编写一些快速脚本来将函数从包含文件复制到输出文件，以代替该source行或只是做一些像这样的琐碎的事情（您必须重新制表，因为make需要制表符）：
all: myscript
myscript: includes/* body/*
cat $^ > "$@" || (rm -f "$@"; exit 1)
然后，您将拥有一个“源”版本（用于编辑）和一个“二进制”版本（用于简单安装）。
答案4
无论是否常见，我认为除了一组出口之外采购任何东西都是一个好主意。我发现通过获取代码来执行代码只是令人困惑，并且它限制了重用，因为环境和其他变量设置使源代码高度依赖于源代码。
您最好将应用程序分解为更小的、独立的脚本，然后将它们作为一系列命令执行。这将简化调试，因为您可以在交互式 shell 中执行每个独立的脚本，在每个命令调用之间检查文件、日志等。您的单个大型应用程序脚本会变成一个更简单的控制脚本，在完成调试后仅运行一系列命令。
一组较小的、独立的脚本确实遇到了难以安装的问题。