命令行可导入numpy但脚本运行失败，求解.cshrc配置问题

这种情况我碰到过好多次，核心原因其实是交互式csh和非交互式csh（运行脚本时）加载环境变量的逻辑不一样——你在命令行启动Python时，shell会加载~/.cshrc里的配置，但直接运行脚本时，默认不会加载这个文件，导致脚本里的Python环境和你交互式使用的完全不是同一个。

下面是一步步排查和解决的方法：

1. 确认脚本使用的Python路径和交互式一致 #

首先，在交互式命令行里执行：

which python  # 或者 which python3，看你日常用的版本

记下输出的绝对路径（比如/usr/local/bin/python3）。然后修改你的Python脚本的第一行shebang，把原来的#!/usr/bin/env python改成这个绝对路径，比如：

#!/usr/local/bin/python3

这样能确保脚本用的是你交互式里能正常导入numpy的那个Python版本，而不是系统默认的、可能缺少numpy依赖的版本。

2. 对比交互式和脚本的环境变量差异 #

接下来要找出两种环境下的变量区别：

• 在交互式shell里执行：

  env > ~/interactive_env.txt
  

• 写一个测试csh脚本test_env.csh：

  #!/bin/csh
  env > ~/script_env.txt
  

  给它加执行权限：chmod +x test_env.csh，然后运行它：./test_env.csh
• 对比两个文件的内容，重点找和Python、numpy相关的变量，比如PYTHONPATH、PATH、LD_LIBRARY_PATH（如果numpy依赖的共享库路径没配置对）。

你大概率会发现，交互式里的PYTHONPATH包含了numpy所在的site-packages目录，但脚本里完全没有这个变量。

3. 让脚本加载必要的环境配置 #

找到差异后，有两种方式让脚本获取正确的环境：

方式一：直接在脚本开头加载~/.cshrc #

如果你的.cshrc里没有只针对交互式shell的判断（比如if ($?prompt) then这类语句），可以在Python脚本的shebang之后，或者在调用Python的csh wrapper脚本里加上：

source ~/.cshrc

比如写一个简单的wrapper脚本run_my_python_script.csh：

#!/bin/csh
source ~/.cshrc
/usr/local/bin/python3 your_script.py

然后运行这个wrapper脚本即可。

如果你的.cshrc里有很多针对交互式的配置（比如设置提示符、命令别名），建议把和Python相关的环境变量单独提取到一个新文件，比如~/.python_env.csh，内容类似：

setenv PYTHONPATH "/path/to/numpy/site-packages:$PYTHONPATH"
setenv LD_LIBRARY_PATH "/path/to/numpy/libs:$LD_LIBRARY_PATH"

然后在~/.cshrc里加上source ~/.python_env.csh，同时在脚本开头也加上这行——这样既不影响交互式的个性化配置，脚本也能拿到必要的变量。

方式二：直接在脚本里设置缺失的变量 #

如果对比后发现只是某个变量缺失，比如PYTHONPATH，可以直接在csh wrapper里设置（比在Python脚本里设置更稳妥，避免模块导入时机问题）：

#!/bin/csh
setenv PYTHONPATH "/path/to/numpy/site-packages:$PYTHONPATH"
/usr/local/bin/python3 your_script.py

4. 检查全局配置加载情况 #

如果以上方法都不行，可能企业IT在全局配置文件里（比如/etc/csh.cshrc或/etc/profile）设置了Python环境，但非交互式shell没有加载这些文件。可以尝试在脚本开头加上：

source /etc/csh.cshrc
source /etc/profile

不过这种情况比较少见，而且因为服务器受IT管理，不要随意修改全局配置文件，优先用用户目录下的配置解决问题。

内容的提问来源于stack exchange，提问作者Gert Gottschalk