是什麼導致 csh 腳本有時無法獲取 /etc/csh.cshrc？
我有一個從 rpm 執行的 csh 安裝後腳本，
%post其解釋器行設置為#!/bin/csh（不帶-f選項）。根據bsd-csh(1)和tcsh(1)的手冊頁，這應該會導致/etc/csh.cshrc在執行腳本的其餘部分之前讀取文件。我有某些系統範圍的環境變數和別名定義，因為腳本依賴於正常執行。預期的行為是，當 csh 執行腳本時，它首先獲取系統範圍的定義，然後腳本成功執行。/etc/csh.cshrc這確實有效，至少在某些條件下最初是這樣。在 rpm
%post部分中始終以相同的方式呼叫 csh 腳本。但是，根據應用程序 rpm install 的執行方式，腳本可能無法獲取預期的變數並出現錯誤，因此在我看來它可能根本沒有採購/etc/csh.cshrc。安裝可以在 root 登錄 shell 中完成，通過 sudo、通過 ssh、從 cron 或從其他程序啟動。其中至少有一個引入了一些阻止/etc/csh.cshrc採購的差異。-f除了會導致此問題的選項之外，我在手冊頁中看不到任何內容。
事實證明，差異是缺少
$HOME環境變數。$HOME環境中未定義時，csh 或 tcsh 根本不提供任何啟動文件。csh對缺少變數的解釋與給定命令行選項$HOME完全相同。-f
~/.cshrc在考慮 shell 啟動文件和~/.login使用者主目錄時，這是有道理的。如果$HOME未定義，則無法載入這些使用者特定文件。$HOME但是，當未定義時，csh 只是跳過查找所有啟動文件，包括系統範圍的和特定於使用者的。在執行 csh 腳本之前定義
$HOME到任何有效目錄，無論它是使用者的真實主目錄還是一個空的臨時目錄，都會使 csh 原始碼/etc/csh.cshrc符合預期。我沒有找到任何文件來解釋或描述這個特性，但是 bsd-csh 和 tcsh 的原始碼都證實了這個行為。