/etc/profile.d 中的脚本有什么作用？

Question

我正在阅读Linux Command Line 和 Shell Scripting Bible 中有关基本 shell 脚本的信息。

它说该/etc/profile文件在 Bash shell 启动时设置了环境变量。该/etc/profile.d目录包含其他包含特定于应用程序的启动文件的脚本，这些脚本也在启动时由 shell 执行。

• 如果这些文件/etc/profile对 Bash 启动也很重要，为什么它们不是其中的一部分？

• 如果这些文件是特定于应用程序的启动文件，对 Bash 启动并不重要，那么它们为什么会成为启动过程的一部分？为什么它们只在包含设置的特定应用程序被执行时才运行？

Answer 1

如果这些文件对 Bash 启动也很重要，为什么它们不是 /etc/profile 的一部分？

如果您的意思是，“为什么不将它们组合成一个巨大的脚本？”，答案是：

1. 因为这对于负责脚本的人来说将是一场维护噩梦。
2. 因为将脚本作为独立模块加载使整个系统的动态可调性更高——可以添加和删除单个脚本而不影响其他脚本。等等。
3. 因为它们是通过 /etc/profile 加载的，这使它们无论如何都以相同的方式成为 bash“配置文件”的一部分。

如果这些文件是特定于应用程序的启动文件，对 Bash 启动并不重要，那么它们为什么会成为启动过程的一部分？为什么它们只在包含设置的特定应用程序被执行时才运行？

在我看来，这更像是一个更广泛的设计哲学问题，我将其一分为二。第一个问题是关于使用shell环境的价值和适当性。它有积极的价值吗？是的，它很有用。它是所有配置问题的最佳解决方案吗？不会，但它对于管理简单的参数非常有效，并且也得到了广泛的认可和理解。相比之下，决定异构配置这些东西，也许 $PATH 可以由一个单独的独立工具管理，首选工具如 $EDITOR 可以在某个地方的 sqlite 文件中，$LC lang 的东西可以在一个带有其他地方的自定义格式等——不只是使用环境变量和/etc/profile.d突然觉得简单了？您可能已经知道 env 变量是什么，它们如何工作以及如何使用它们，而不是学习 5 种完全不同的机制，用于适当命名为“环境”的5 个不同普遍方面。

第二个问题是，“启动时间是否合适？”，这引起了人们的反对，认为它不是很有效（所有可能会或可能不会被使用的数据等）。但：

• 实际上，它并不是所有的数据，部分原因是没有人会使用它来处理几个简单的参数（因为还有其他配置应用程序的方法）。
• 如果明智地使用它，对于通常调用的事物，那么设置，例如，每次调用时从某个文件中的默认 $CFLAGSgcc将效率较低。请记住，所涉及的内存量也是无穷小的。
• 它可能涉及多个应用程序可能涉及的系统性事物，而外壳是一个共同点。

可以将更多内容添加到该列表中，但希望这能让您对问题的利弊有所了解——主要的“优点”和主要的“缺点”是它是一个全局命名空间。

Answer 2

这些文件特定于应用程序，但在 shell 启动时提供，而不是在应用程序启动时提供。此处使用配置目录的原因与在许多其他地方可以找到的原因相同。这允许应用程序或软件包修改配置。如果没有拆分配置，这是不可能的，因为多个包试图管理/更新也可以由用户修改的单个配置文件，这将是错误和混乱的。

还有一个旁注，/etc/profile来自所有 shell，而不仅仅是 bash。bash 特定的配置文件是 bashrc 并且仅用于交互式 shell。

Answer 3

乔丹的回答是不正确的。/etc/profile并非所有 shell 都来源于此。正如您所指出的，它不是由csh, tcsh- 我不确定zsh。它源自 Bourne shell ( sh) 衍生品，例如 Korn Shell ( ksh) 和 BASH ( bash)。csh使用/etc/login. 倾向于只使用 Borne Shell 衍生物的人往往会忘记其他 shell 的存在。他们添加了一些东西来/etc/profile期望它适用于“所有用户”，然后当奇怪的 C Shell 用户（我们是奇怪的人）没有他们在/etc/profile.

即便如此，人们往往会忘记其他 Borne Shell 衍生 shell 的存在。如果他们使用bashor ksh，他们可以随意添加/etc/profile在 Bourne Shell 中无效的语法，比如定义一个变量并在同一行导出它。然后你得到了一些可以执行的脚本，#!/bin/sh但它的语法很混乱。/etc/profile应坚持 Bourne Shell 兼容语法。

同样，您应该坚持自己使用它.profile（.bash_profile如果您想要一些 bash 语法，请使用它）——这可能需要一些额外的输入，但这是您一次性完成的额外输入。参考${HOME}和不等~。某些风格的 Unix、cron 作业在 下运行sh，每一行都由Makefile处理，因此，如果您在多种风格的 UNIX 上工作，保持Bourne shell 兼容sh确实值得。.profile作为一名系统管理员，我无法告诉你有多少次我帮助别人修复了.profileBourne Shell 兼容问题。

在 Linux 上，/bin/sh是一个链接/bin/bash，当您运行它时，它看起来是用于运行它的路径，并且（理论上）将其自身限制为仅 Bourne Shell 支持的内容。同样，vi在 Linux 上确实vim再次限制了自己。有时您会看到功能“渗透”。偶尔vim假装会做一些支持但不支持的vi事情，因为作者忘记在“vi 向后兼容”模式下禁用它。如果假装具有一些类似的“渗透”功能，我不会感到惊讶。如果某些功能“适用于 Linux 上的 Borne Shell”，但不适用于基于 System V 或 BSD 的 UNIX（AIX、OpenBSD 等），也不会感到惊讶。vimvivimbashsh