centos 7的crontab默认用/bin/sh（非用户登录shell）执行脚本，不加载~/.bashrc等配置，导致bash特有语法报错；解决方式为显式指定解释器（如#!/bin/bash+可执行权限，或crontab中写/bin/bash /path/to/script.sh），并手动设置path、使用绝对路径、重定向错误日志。
CentOS 7 的定时任务（crontab）默认用 /bin/sh 执行脚本，不是你当前用户设置的 /bin/bash 或 /usr/bin/fish —— 这会导致语法报错（比如 [[、source、数组、$(()) 等 bash 特有功能直接失败）。
为什么 crontab 不认你的 ~/.bashrc 或 chsh 设置
crond 是系统级守护进程，它启动时不会加载用户 shell 配置文件，也不读取 /etc/passwd 中的 shell 字段。它硬编码使用 /bin/sh（在 CentOS 7 上是 bash 的 POSIX 兼容模式，禁用了扩展语法）来解析每行命令。
- 即使你用
chsh -s /bin/bash改了登录 shell，crontab -e里写的命令仍走/bin/sh -
~/.bashrc、~/.bash_profile在 cron 环境中完全不生效 - 环境变量如
$PATH极简（通常只有/usr/bin:/bin），没你的自定义路径
让 cron 脚本用 bash 执行的三种可靠方式
核心原则：显式指定解释器，不依赖环境或默认行为。
- 在脚本第一行加
#!/bin/bash，并确保脚本有执行权限（chmod +x /path/to/script.sh），然后在 crontab 里直接调用该脚本路径（如0 * * * * /home/user/task.sh） - 在 crontab 条目里强制指定 shell：
0 * * * * /bin/bash /home/user/task.sh - 如果必须在 crontab 行内写命令（非独立脚本），用
bash -c包裹：0 * * * * bash -c 'source /home/user/.bashrc; echo $(date); /usr/local/bin/mytool'
常见错误：PATH 和环境变量丢失
即使指定了 /bin/bash，cron 仍没有你的交互式 shell 的环境变量。典型症状是命令找不到（command not found）、source 失败、Python 脚本导入模块报错。
CentOS Linux 7.9.2009是传统CentOS Linux 7的最后主要版本，也是很多企业历史服务器中仍可能遇到的系统版本。它以稳定、兼容RHEL 7生态、文档丰富和软件支持广泛著称，曾长期用于Web服务、数据库、虚拟化节点和企业内部业务系统。不过CentOS Linux 7已于2024年6月30日停止维护，现在继续使用会面临安全补丁缺失风险。该版本更适合旧业务迁移、历史环境恢复或离
- 不要依赖
$HOME自动展开：写绝对路径，如/home/user/.bashrc而非~/.bashrc - 显式设置
PATH：在脚本开头加PATH=/usr/local/bin:/usr/bin:/bin，或在 crontab 条目前加PATH=... - 避免在脚本里用
which或type判断命令存在——它们依赖$PATH，而 cron 的$PATH很窄 - 调试时重定向 stderr：
0 * * * * /bin/bash /home/user/task.sh 2>>/tmp/cron.err，否则错误静默消失
验证 cron 实际使用的 shell 和环境
临时加一条测试任务，把真实环境 dump 出来：
*/1 * * * * /bin/bash -c 'echo "SHELL: $SHELL" > /tmp/cron_env.log; echo "PATH: $PATH" >> /tmp/cron_env.log; echo "UID: $UID" >> /tmp/cron_env.log; date >> /tmp/cron_env.log'
一分钟后检查 /tmp/cron_env.log，你会看到 SHELL 是空或 /bin/sh，PATH 极短 —— 这就是你要适配的真实上下文。
真正起作用的不是“改系统默认 shell”，而是让每个 cron 条目或脚本自己声明解释器和环境。忽略这点，只改 chsh 或 /etc/passwd，任务照样失败。
