文件系统层次结构标准-在何处放置可源函数？

我有一些运行系统检查的bash脚本。这些脚本从文件/ etc / healthchecks / config中获取配置选项。

除了配置文件，我还有一个共享功能文件。脚本应该能够找到该文件并在其中运行功能。

基于文件系统层次结构标准，应该将共享功能文件放在哪里？它不是一个配置，因此它似乎不属于/ etc，但是它也未被执行，因此/ usr / bin似乎不正确。也许/ usr / lib？

您应该将healthchecks可执行文件放在/ usr / local / bin或/ opt / bin中。如果您看到/ opt文件夹为空，则表示您的Linux发行版不使用它。因此，合适的位置将是/ usr / local。

/ usr / local和/ opt是必须放置每个“手动”软件包/程序的位置。/ usr用于由程序包管理器（即dpkg）管理的程序包。根据FHS，/ opt是手动软件包的“标准位置”，但是debian发行版改用/ usr / local。

对于配置文件，必须将它们放置在/ usr / local / etc上，因为/ etc用于自动软件包和其他系统程序的配置文件。

然后，共享功能的正确位置是/ usr / local / share（/ usr / share用于自动软件包的共享文件）。每个设计为只读且独立于Arquitecture的文件都属于/ usr / share或/ usr / local / share（如果它们由“自动”或“手动”软件包拥有）。

/ usr / lib用于动态和静态二进制库（.so或.a），而不用于“解释”的库/函数。

通常，对于每个版本，解释器在/ etc / share /中都有不同的子文件夹，并且在每个版本文件夹中，脚本，语言环境，测试，示例等的文件夹都不同。

如果有一天您为软件包创建了一个正式的存储库healthchecks，则可以将/ usr / local / healthchecks内容迁移到/ usr / healthchecks和/ etc / healthchecks。

我通常会尝试将站点特定的内容保留在这些保留的系统区域之外。您可能会考虑使用自己的顶级目录层次结构，因为在使用系统区域时，特殊站点文件很容易在系统演进过程中丢失或遗忘。另一种可能是/ usr / local / etc .....