/etc/profile.d中的脚本做什么？

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

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

• 如果这些文件/etc/profile对于Bash启动也很重要，为什么不包含这些文件？

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

如果这些文件对Bash启动也很重要，为什么它们不属于/ etc / profile？

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

1. 因为这将是负责脚本的人员的维护噩梦。
2. 因为将脚本作为独立的模块加载使整个系统更具动态可调性，所以可以添加和删除单个脚本而不会影响其他脚本。等等。
3. 因为它们是通过/ etc / profile加载的，所以无论如何它们都是bash“ profile”的一部分。

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

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

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

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

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

这些文件特定于应用程序，但在外壳启动时而不是在应用程序启动时来源。此处使用配置目录的原因与在其他许多地方都可以找到它的原因相同。这允许应用程序或软件包修改配置。如果没有拆分的配置，这将是不可能的，因为试图管理/更新单个配置文件（用户也可以对其进行修改）的多个软件包会出现故障和混乱。

另外，/etc/profile所有shell都提供了一个旁注，而不仅仅是bash。bash特定的配置文件是bashrc，仅用于交互式shell。

约旦的答案不正确。/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衍生壳的存在。如果使用bash或ksh，则可以随意/etc/profile在Bourne Shell中添加无效的语法，例如定义变量并将其导出在同一行上。然后，您将获得执行#!/bin/sh该脚本的脚本，并且该脚本使语法令人窒息。/etc/profile应该坚持使用Bourne Shell兼容语法。

同样，您应该自己坚持使用它.profile（.bash_profile如果需要一些bash语法，请使用）-可能需要额外输入一些内容，但是您需要一次完成所有额外输入。参考，${HOME}而不是参考~。等等。某些类型的Unix，cron作业在下运行sh，您的每一行Makefile均由处理sh，因此，如果您跨多种类型的UNIX工作，则保持.profileBourne Shell兼容确实是值得的。作为SysAdmin，我无法告诉您我已经通过修复某个人使其.profile与Bourne Shell兼容的方式为他人提供了帮助。

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