bash 脚本报 $'\r': command not found / bad interpreter: /bin/bash^M——Windows 换行符（CRLF）混入

症状

在 WSL/Linux 上执行 Windows 里写好的脚本，报出两类典型错误：

```

$ bash setup.sh

setup.sh: line 2: $'true\r': command not found

$ ./setup.sh

bash: ./setup.sh: /bin/bash^M: bad interpreter: No such file or directory

```

- 报错里的 `\r`（或 `^M`）是肉眼看不到的换行残留——用记事本/Windows 编辑器保存的脚本会带上。

- 有的脚本看起来「部分能跑」，某几行命令突然 `command not found`——正是那些行尾带 CR 的命令。

原因

1. Windows 文本文件用 CRLF（\r\n）结尾，Linux 只用 LF（\n）。

2. **命令名后带 CR**：bash 把 `true\r` 当成一个整体命令名 → `$'true\r': command not found`（CR 在 echo 参数里通常不报错，所以「时好时坏」）。

3. **shebang 行带 CR**：`#!/bin/bash\r` 让内核去找 `/bin/bash\r`（^M）这个解释器 → `bad interpreter`。

4. 常见来源：记事本保存、Windows 编辑器默认 CRLF、git 检出配置不当（`core.autocrlf` 相关，见 git-crlf 条目）。

解法

1. **快速修复（转换换行符）**：

```

sed -i 's/\r$//' setup.sh

# 或 dos2unix setup.sh

```

2. **如果只有 shebang 行坏**：`bash setup.sh` 显式调用解释器可绕过 shebang 解析（但正文 CR 仍在）；根治还是去 CR。

3. **预防**：在 Linux 内编辑脚本（vi/nano）；Windows 编辑器选 LF/Unix 换行；git 仓库统一 `core.autocrlf` 策略（与 git-crlf 条目互补）；复制脚本后先 `file setup.sh` 看一眼（显示 `with CRLF` 即中招）。

验证证据

- 本机（WSL Ubuntu 6.18.35.2，bash 5.3.9，2026-08-29）：

- 实测 1（正文 CR）：`printf '#!/bin/bash\ntrue\r\n'` + `bash` → `line 2: $'true\r': command not found`，exit=127——与用户报错逐字一致。

- 实测 2（shebang CR）：`#!/bin/bash\r` + `chmod +x` + `./` 执行 → `/bin/bash^M: bad interpreter: No such file or directory`，exit=126。

- 实测 3（修复）：`sed -i 's/\r$//'` 后脚本正常，exit=0。

- dos2unix 未安装（示例命令如实给出，未实测）。

- 实测复现日志（2026-08-29）