linux脚本自动化失败主因是忽略运行上下文：权限问题需检查脚本及调用命令权限、挂载选项noexec；路径应使用$(cd “$(dirname “${BASH_SOURCE[0]}”)” && pwd)动态获取；cron需显式定义PATH或导出变量；交互命令须改用密钥、配置文件等免交互方式。
Linux脚本自动化不是写完就能跑通，很多新手卡在看似简单的地方——比如权限不对、路径写死、环境变量缺失，或者误把交互式命令直接塞进脚本里。关键不是“会不会写”，而是“有没有考虑运行上下文”。
脚本没权限？别急着加sudo
chmod +x 脚本.sh 是基础操作，但更常见的是：脚本里调用的命令本身没权限（比如需要 root 的 systemctl），或脚本放在 NFS/usb 等挂载点上，执行权限被挂载选项禁用了（noexec）。检查方式很简单：
- 用 ls -l 脚本.sh 确认有 x 权限
- 用 mount | grep $(df . | tail -1 | awk ‘{print $1}’) 看当前分区是否挂载了 noexec
- 如果必须提权，优先用 sudo -n（非交互）+ 配置 /etc/sudoers 免密，而不是在脚本里硬写密码
路径写死 = 脚本一换位置就失效
写成 /home/user/scripts/do_backup.sh 看似清晰，实际换个用户、换个机器就报错。正确做法是让脚本“认识自己”：
- 用 DIR=$(cd “$(dirname “${BASH_SOURCE[0]}”)” && pwd) 获取脚本所在绝对路径
- 所有依赖文件（配置、日志、模板）都用 $DIR/../conf 或 $DIR/data 这类相对路径引用
- 避免用 ~ 或 $HOME 直接拼路径，某些 cron 环境下 $HOME 可能为空或指向 root
在终端能跑，放进crontab就失败？环境不一样
cron 默认只加载 minimal 环境变量，PATH 往往只有 /usr/bin:/bin，连 python3 都可能找不到。这不是脚本问题，是执行环境缺失：
- 在 crontab 里显式定义 PATH：PATH=/usr/local/bin:/usr/bin:/bin
- 脚本开头加 source ~/.bashrc 不可靠（cron 不读它），改用 source /etc/environment 或直接 export 所需变量
- 调试技巧：在 crontab 里先重定向输出，* * * * * /path/to/script.sh >> /tmp/cron.log 2>&1，再看报错
别把交互式命令当自动命令用
像 ssh user@host、mysql -u root -p 这类命令默认等待人工输入，在脚本里会卡住。自动化必须消除交互：
- ssh 用密钥认证（ssh-keygen + ssh-copy-id），禁用密码登录
- mysql 用配置文件 ~/.my.cnf 存账号密码，权限设为 600
- 实在要传参，用 echo “password” | command –stdin 类方式，但注意安全性（进程参数可能被 ps 看到）
基本上就这些——不复杂，但容易忽略。写脚本前多问一句：“它离开我当前终端、当前用户、当前目录，还能不能活？”答案清楚了，坑就避开一大半。