我正在从Linux Command Line和Shell Scripting Bible阅读有关基本Shell脚本的信息。
它说该/etc/profile文件在Bash shell启动时设置环境变量。该/etc/profile.d目录包含其他脚本，这些脚本包含特定于应用程序的启动文件，这些启动文件在外壳启动时也会执行。
如果这些文件/etc/profile对于Bash启动也很重要，为什么不包含这些文件？
如果这些文件是特定于应用程序的启动文件，对于Bash启动而言并不重要，那么为什么它们是启动过程的一部分？为什么它们不仅在执行包含它们的设置的特定应用程序时运行？
如果这些文件对于Bash启动也很重要，为什么它们不属于/ etc / profile呢？
如果您的意思是“为什么不将它们组合成一个巨大的脚本？”，答案是：
如果这些文件是特定于应用程序的启动文件，对于Bash启动而言并不重要，那么为什么它们是启动过程的一部分？为什么它们不仅在执行包含它们的设置的特定应用程序时运行？
在我看来，这就像是一个更广泛的设计哲学问题，我将一分为二。第一个问题是关于使用Shell环境的价值和适当性。它有正面价值吗？是的，它很有用。它是解决所有配置问题的最佳解决方案吗？否，但是它对于管理简单参数非常有效，并且也得到广泛认可和理解。相比之下，决定异种地配置这些东西，也许$ PATH可以由单独的独立工具管理，首选工具（例如$ EDITOR）可以在某个地方的sqlite文件中，$ LC lang的东西可以在一个文本文件中，并带有一个自定义格式在其他地方，等等-不只是使用env变量和/etc/profile.d突然看起来更简单？您可能已经知道env变量是什么，它们如何工作以及如何使用它们，而相对于学习5种完全不同的机制来了解适当命名为“环境”的5个不同普遍性方面而言。
第二个问题是“启动时间是否合适吗？”，这引起了反对，即效率不是很高（可能会使用或可能不会使用的所有数据，等等）。但：
gcc都从某个位置的文件中设置默认的$ CFLAGS会降低效率。请记住，所涉及的内存量同样是无限的。可以将更多内容添加到该列表中，但是希望这可以使您对问题的利弊有所了解-主要的“优点”和主要的“缺点”是它是全局命名空间。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句