crontab 默认通过 /bin/sh 执行脚本；在 CentOS 7 中，这个 shell 通常指向 bash 的 POSIX 兼容模式，因此不支持 [[ ]]、source、数组等 bash 专属语法。同时，cron 的 PATH 环境非常精简，也不会主动加载用户配置文件，所以经常会出现手动执行正常、但定时任务运行失败的问题。
crontab 默认用什么 Shell 执行脚本
在 CentOS 7 系统中，crond 守护进程执行 crontab 定时任务时，默认使用的是 /bin/sh，而不是很多人以为的 /bin/bash。也就是说，无论当前登录用户使用的是 bash、zsh 还是其他 shell，到了 cron 定时任务环境中，实际调用的仍然是 /bin/sh。这并非偶然现象，而是 crond 的默认设计决定的，因此仅靠用户环境变量，例如 $SHELL，并不能把默认解释器切换成 bash。
为什么脚本在 crontab 里执行失败，但手动运行正常
最常见的情况是：脚本里使用了 [[ ]] 、source ~/.bashrc、数组、$(date -d ...) 等 bash 特有写法，手动执行时一切正常，但放进 crontab 后却报错、无输出，甚至直接静默失败——这通常就是因为脚本被 /bin/sh 解释执行，相关语法无法被识别。
/bin/sh在 CentOS 7 中通常链接到bash的 POSIX 兼容模式，不支持[[、let、declare、source（只支持.）、大括号扩展等 bash 语法- 环境变量不完整：
PATH很短（一般只有/usr/bin:/bin），HOME可能异常，~路径展开也可能失效 - 不会加载用户的 profile 或 rc 配置文件，因此自定义的 alias、shell 函数、额外 PATH 设置等内容都不会生效
强制 cron 用 bash 执行单个脚本的 3 种可靠方式
与其修改系统级默认 shell（通常没必要，也不建议这样做），更稳妥的方式是让定时任务自行指定脚本解释器：
- 在脚本首行明确写上
#!/bin/bash，并确认脚本具有执行权限（chmod +x /path/to/script.sh），然后在 crontab 中直接调用脚本完整路径——这是最常见、最安全、也最推荐的方案 - 在 crontab 任务项中直接显式调用 bash：
0 2 * * * /bin/bash /home/user/backup.sh >> /var/log/backup.log 2>&1 - 在脚本开头加入
set -e -u，并为所有命令使用完整路径（如/usr/bin/date），尽量避免依赖 PATH；同时使用.代替source，用[ ]替代[[ ]]——这种方式是让脚本兼容/bin/sh，但可读性和功能灵活性会有所下降
不要碰 /etc/crontab 的 SHELL= 行
不要被 /etc/crontab 文件顶部的 SHELL=/bin/bash 误导，它只对 /etc/crontab 中定义的系统级定时任务有效，前提还是该文件由 root 维护并由系统正确加载。对于普通用户通过 crontab -e 添加的任务，这一行完全不起作用——这是 crond 的设计机制，不属于 bug。
如果强行修改这类全局配置，还有可能在系统升级后被覆盖，甚至影响其他依赖 cron 的服务，例如 logrotate。真正需要使用 bash 的情况下，也应该只在 /etc/crontab 中为特定 root 任务单独加上 /bin/bash -c '...' 进行包裹，而不是直接全局修改默认解释器。
核心结论其实很简单：cron 不会因为你登录时使用什么 shell，就自动继承对应解释器；它只按自己的规则执行。想让 CentOS 7 的 crontab 或系统级定时任务使用 bash，最可靠的方法就是在脚本开头明确写上 #!/bin/bash，或者在 crontab 中显式调用 /bin/bash，不要依赖环境变量或全局配置来“自动修复”执行环境。
