我之前也踩过这个坑，咱们来拆解下具体原因：

1. Cron默认用非Bash的Shell执行任务 #

大多数Linux系统里，Cron的默认执行Shell是sh（通常是dash的软链接），而BASH_SOURCE是</think_never_used_51bce0c785ca2f68081bfa7d91973934>Bash专属的变量——sh/dash根本不支持这个变量。当你在Crontab里直接写source /path/to/your/script.sh时，Cron会用sh去执行，此时BASH_SOURCE压根不存在，自然是空值。

2. 就算指定Bash，-c参数模式下BASH_SOURCE行为不符合预期 #

如果你在Crontab里明确指定用Bash执行，比如：

* * * * * bash -c 'source /path/to/your/script.sh'

Bash会把-c传递的命令字符串当作"主输入"，这时${BASH_SOURCE[0]}会被设为-c，而不是你source的脚本路径。这和你在交互式Bash里直接source script.sh完全不同——交互式场景下，Bash明确知道你正在加载哪个文件，所以会把文件路径正确赋值给BASH_SOURCE。

3. Cron的执行环境没有交互式Shell的上下文 #

命令行的交互式Shell会维护会话上下文，包括跟踪你正在source的脚本信息。但Cron启动的是一个极简的非交互式Shell，没有这类上下文，它不会像终端Shell那样跟踪source操作，所以BASH_SOURCE根本不会被填充脚本路径。

如果你必须保持source脚本的操作（而不是直接执行），可以试试这几个可靠的方案：

方案1：通过环境变量显式传递脚本路径 #

修改Crontab任务，先导出脚本路径再source：

* * * * * export SCRIPT_PATH="/完整路径/your/script.sh"; bash -c '. "$SCRIPT_PATH"'

然后修改你的脚本，当BASH_SOURCE为空时 fallback 到这个环境变量：

#!/bin/bash
if [[ -n "${BASH_SOURCE[0]}" ]]; then
    FILE_NAME=$(realpath "${BASH_SOURCE[0]}")
else
    FILE_NAME=$(realpath "$SCRIPT_PATH")
fi
FILE_DIR=$(dirname "$FILE_NAME")

方案2：用 wrapper 脚本避免-c参数 #

如果你的场景允许，可以写一个包装脚本，让它去source目标脚本，然后Cron直接执行这个包装脚本：

# wrapper.sh 内容
#!/bin/bash
. /完整路径/your/target_script.sh
# 这里可以加source后需要执行的命令

然后Crontab任务写成：

* * * * * bash /完整路径/wrapper.sh

这种情况下，target_script.sh里的BASH_SOURCE就能正常工作了，因为它是从一个标准的Bash脚本文件里被source的，不是从-c的命令字符串里。

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