非交互式 Shell 默认不加载任何配置文件，因其设计上跳过登录与交互流程；需在脚本开头用 source 显式导入 ~/.bashrc、/etc/profile 等，并确保变量已 export，或改用 bash -l 启动登录 Shell。
非交互式 Shell 默认不加载任何启动配置文件（/etc/profile、~/.bashrc 等），所以环境变量不会自动生效。要让它能读取并使用你定义的变量，必须手动显式加载。
为什么非交互式 Shell 不加载环境变量
这类 Shell 常见于脚本执行、crontab 任务、Ansible 远程命令等场景。它不与用户交互，也不走登录流程，因此跳过所有 profile 和 bashrc 的自动加载机制。这是设计使然，不是 bug。
在脚本中主动 source 配置文件
最常用且可靠的做法是在脚本开头用 source（或点号 .）导入所需配置：
-
source ~/.bashrc—— 加载当前用户的个人环境（推荐用于单用户场景） -
source /etc/profile—— 加载系统级全局环境（适合多用户或需 PATH 等基础变量时） -
source /etc/profile.d/myenv.sh—— 加载特定自定义环境脚本（更轻量、易维护）
注意：source 必须在脚本内执行，不能靠外部 shell 启动时“带进去”。写成 #!/bin/bash -i 强制交互模式是错误做法，可能引发不可预期行为。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
确保变量已 export 并适用于子进程
仅在 .bashrc 里写 PATH=/new/path:$PATH 是不够的，必须显式导出：
-
export PATH—— 把变量标记为环境变量，使其可被后续命令继承 -
export JAVA_HOME=/opt/jdk—— 自定义变量也要 export 才有效 - 检查是否生效：在脚本中加一句
echo $JAVA_HOME或env | grep JAVA_HOME
替代方案：用 login shell 启动非交互式任务
某些场景下（如 crontab），可以改用登录 Shell 方式触发，让系统自动加载 profile：
-
0 2 * * * /bin/bash -l -c 'my_script.sh'——-l表示 login shell，会加载/etc/profile和~/.bash_profile -
su -l username -c 'command'—— 切换用户并模拟完整登录环境
这种方式更“标准”，但略重；适合需要完整用户环境的长期任务。
