GitHub远程Bash脚本执行失败排查（Windows10环境）

这个问题我之前踩过一模一样的坑！本质就是换行符格式不兼容在搞鬼：Bash只认Unix风格的LF换行符，但你的脚本里混进了Windows的CRLF（也就是\r\n）。当你直接用curl拉取并管道给bash执行时，Bash会把行尾的\r当成命令的一部分，自然就报出/dev/fd/63: line 7: $'\r': command not found这种错——而你逐行复制粘贴时，终端会自动帮你把CRLF转换成LF，所以不会出问题。

下面给你几个实用的解决办法：

1. 管道执行时直接过滤回车符 #

可以在curl获取脚本后，用tr或者sed直接去掉所有\r字符，再传给bash执行：

• 用tr的命令（简单粗暴，直接删除所有回车符）：

curl -s https://raw.githubusercontent.com/your-repo/your-script.sh | tr -d '\r' | bash

• 用sed的命令（更精准，只删除行尾的\r）：

curl -s https://raw.githubusercontent.com/your-repo/your-script.sh | sed 's/\r$//' | bash

2. 先下载脚本，转换格式后再执行 #

如果担心管道处理可能有其他潜在问题，可以先把脚本下载到本地，转换换行符后再运行：

# 下载脚本到本地临时文件
curl -s -o temp_script.sh https://raw.githubusercontent.com/your-repo/your-script.sh

# 方法一：用dos2unix转换（多数Linux发行版自带这个工具）
dos2unix temp_script.sh

# 方法二：如果没有dos2unix，用sed修改本地文件
sed -i 's/\r$//' temp_script.sh

# 执行处理后的脚本
bash temp_script.sh

3. 从根源修复：确保脚本是LF换行符 #

如果这个脚本是你自己维护的，建议直接在本地编辑器里把换行符设置为LF，再重新提交到GitHub：

• 比如VS Code可以点击右下角的换行符标识（显示CRLF的地方），切换成LF；
• 也可以在Git里设置自动转换：git config --global core.autocrlf input，这样提交时会自动把CRLF转换成LF，从根源避免这类问题。

试试上面的方法，应该就能彻底解决这个烦人的报错了！

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