我有一个 csh 安装后脚本，该脚本是从 rpm 执行的%post，其解释器行设置为#!/bin/csh（不带-f选项）。/etc/csh.cshrc根据两者的手册页，这应该会导致在执行脚本的其余部分之前读取文件bsd-csh(1)和tcsh(1)。我有某些系统范围的环境变量和别名定义，/etc/csh.cshrc脚本依赖于它们才能正常运行。预期的行为是，当 csh 执行脚本时，它首先获取系统范围的定义，然后脚本成功运行。
这确实有效，至少在某些条件下是这样。 csh 脚本始终从 rpm%post部分以相同的方式调用。但是，根据应用程序 rpm 安装的执行方式，脚本可能无法获取预期的变量并出错，因此在我看来它可能/etc/csh.cshrc根本没有采购。安装可以在 root 登录 shell 中通过 sudo、通过 ssh、从 cron 完成，或者从其他进程启动。其中至少有一个引入了一些阻止/etc/csh.cshrc来源的差异。除了-f会导致此问题的选项之外，我在手册页中没有看到任何内容。
答案1
事实证明，差异是缺少$HOME环境变量。如果$HOME环境中未定义 ，则 csh 或 tcsh 根本不会获取任何启动文件。 csh对缺少变量的解释与给定命令行选项$HOME的解释完全相同。-f
当考虑 shell 启动文件~/.cshrc和~/.login用户主目录时，这是有意义的。如果$HOME未定义，则无法加载这些用户特定的文件。但是，当$HOME未定义时，csh 会简单地跳过查找所有启动文件，包括系统范围的启动文件和特定于用户的启动文件。
在执行 csh 脚本之前定义$HOME任何有效目录，无论是用户的真实主目录还是空的临时目录，都会使 csh 源代码/etc/csh.cshrc符合预期。
我没有找到任何文档来解释或描述此功能，但 bsd-csh 和 tcsh 的源代码证实了此行为。
答案2
确保 csh 确实正在运行！
运行which csh以获取 csh 的位置。
跑步ls -l /path/returned/by/which/csh
就我而言，不知何故csh被映射到tcsh.