我正在阅读有关基本 shell 脚本的内容Linux 命令行和 Shell 脚本圣经。
它表示该/etc/profile
文件在 Bash shell 启动时设置环境变量。该/etc/profile.d
目录包含其他脚本,其中包含特定于应用程序的启动文件,这些文件也在启动时由 shell 执行。
/etc/profile
如果这些文件对于 Bash 启动也很重要,为什么不包含在其中?如果这些文件是特定于应用程序的启动文件,对于 Bash 启动并不重要,那么为什么它们是启动过程的一部分?为什么它们不只在执行它们包含设置的特定应用程序时运行?
答案1
如果这些文件对于 Bash 启动也很重要,为什么它们不是 /etc/profile 的一部分?
如果您的意思是“为什么不将它们合并成一个巨大的脚本?”,答案是:
- 因为这对于负责脚本的人员来说将是一场维护噩梦。
- 因为将脚本作为独立模块加载可以使整个系统更加动态地调整——可以添加和删除单个脚本而不影响其他脚本。 ETC。
- 因为它们是通过 /etc/profile 加载的,这使得它们以相同的方式成为 bash“配置文件”的一部分。
如果这些文件是特定于应用程序的启动文件,对于 Bash 启动并不重要,那么为什么它们是启动过程的一部分?为什么它们不只在执行它们包含设置的特定应用程序时运行?
在我看来,这是一个更广泛的设计哲学问题,我将把它分成两个。第一个问题是关于使用 shell 环境的价值和适当性。它有积极的价值吗?是的,它很有用。它是所有配置问题的最佳解决方案吗?不是,但它对于管理简单参数非常有效,并且也得到了广泛的认可和理解。相比之下,决定异构地配置这些东西,也许 $PATH 可以由单独的独立工具管理,首选工具(例如 $EDITOR)可以在某个地方的 sqlite 文件中,$LC lang 内容可以在带有其他地方的自定义格式等等——不只是使用环境变量并且/etc/profile.d
突然看起来更简单吗?您可能已经知道环境变量是什么、它们如何工作以及如何使用它们,而不是学习 5 种完全不同的机制来了解环境变量的 5 个不同的普遍方面。适当命名“环境”。
第二个问题是,“启动是适当的时间吗?”,这引起了反对意见,认为它不是很有效(所有可能会或可能不会使用的数据等)。但:
- 实际上,它并不是那么多数据,部分原因是没有一个头脑正常的人会使用它来处理几个简单的参数(因为还有其他方法来配置应用程序)。
- 如果明智地使用它,对于经常调用的东西,那么每次调用时从某个文件中设置默认的 $CFLAGS 等
gcc
都会降低效率。请记住,所涉及的内存量同样是无穷小的。 - 它可能涉及系统性的事情,可能涉及多个应用程序,而 shell 是一个共同点。
可以在该列表中添加更多内容,但希望这能让您了解该问题的优缺点——主要的“优点”和主要的“缺点”是它是一个全局名称空间。
答案2
这些文件特定于应用程序,但源自 shell 启动时,而不是应用程序启动时。此处使用配置目录的原因与在许多其他地方找到它的原因相同。这允许应用程序或软件包修改配置。如果没有拆分配置,这是不可能的,因为尝试管理/更新也可以由用户修改的单个配置文件的多个包将会出现错误和混乱。
另外需要注意的是,/etc/profile
它是由所有 shell 提供的,而不仅仅是 bash。 bash 特定的配置文件是 bashrc,仅适用于交互式 shell。
答案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 的存在。如果他们使用bash
or ksh
,他们可以随意添加/etc/profile
在 Bourne Shell 中无效的语法,比如定义一个变量并在同一行导出它。然后你得到了一些可以执行的脚本#!/bin/sh
,但它的语法很混乱。/etc/profile
应坚持 Bourne Shell 兼容语法。
同样,您应该坚持自己使用它.profile
(.bash_profile
如果您想要一些 bash 语法,请使用它)——这可能需要一些额外的输入,但这是您一次性完成的额外输入。参考${HOME}
和不等~
。某些风格的 Unix、cron 作业在 下运行sh
,每一行Makefile
都由 处理sh
,因此,如果您在多种风格的 UNIX 上工作,保持.profile
Bourne shell 兼容确实值得。作为一名系统管理员,我无法告诉你有多少次我帮助别人修复了.profile
Bourne Shell 兼容问题。
在 Linux 上,/bin/sh
是一个链接/bin/bash
,当您运行它时,它看起来是用于运行它的路径,并且(理论上)将其自身限制为仅 Bourne Shell 支持的内容。同样,vi
在 Linux 上确实vim
再次限制了自己。有时您会看到功能“渗透”。偶尔vim
假装vi
会做一些vim
支持但不支持的事情vi
,因为作者vim
忘记在“vi 向后兼容”模式下禁用它。如果bash
假装sh
具有一些类似的“渗透”功能,我不会感到惊讶。如果某些功能“适用于 Linux 上的 Borne Shell”,但不适用于基于 System V 或 BSD 的 UNIX(AIX、OpenBSD 等),也不会感到惊讶。