解决Linux脚本执行报错：CRLF换行符问题分析与处理

1. 问题现象与初步分析

最近在部署一个Java应用时，执行启动脚本start_app.sh时遇到了奇怪的报错：

code复制start_app.sh: line 2: $'\r': command not found
start_app.sh: line 5: $'\r': command not found
start_app.sh: line 11: $'\r': command not found
 进程...所有旧的 no_database_demo-1.0-SNAPSHOT
start_app.sh: line 33: syntax error: unexpected end of file

这个错误看起来非常诡异——脚本中明明没有调用什么\r命令，但系统却提示找不到这个"命令"。更奇怪的是，最后还出现了语法错误，提示文件意外结束。

经过排查，这实际上是Linux/Unix系统中非常经典的一个问题：脚本文件的换行符格式不正确。具体来说，这个脚本是在Windows环境下编写或编辑过的，使用了Windows的CRLF（\r\n）换行符，而Linux系统只能正确识别Unix格式的LF（\n）换行符。

提示：CRLF是"Carriage Return + Line Feed"的缩写，即回车+换行，对应ASCII码是\r\n；而LF是"Line Feed"的缩写，即换行，对应ASCII码是\n。

2. 问题根源深入解析

2.1 为什么换行符会导致命令找不到

当Linux的shell（如bash）尝试执行一个脚本时，它会逐行读取并解释脚本内容。如果脚本使用的是CRLF换行符：

1. shell会看到每行末尾的\r字符
2. 由于\r在Unix中是一个合法的字符（回车符），shell会尝试将其作为命令执行
3. 但系统中并没有名为\r的命令，因此报错"command not found"

2.2 为什么会出现语法错误

CRLF换行符还会导致脚本解析异常：

1. shell会将\r视为行内容的一部分
2. 这可能导致原本合法的语法结构被破坏
3. 例如，if语句的fi标记可能因为前面的\r而无法正确匹配
4. 最终导致脚本在未预期的地方结束，报"unexpected end of file"错误

2.3 如何确认文件格式

在Linux系统上，有几种方法可以检查文件的换行符格式：

1. 使用file命令：

   bash复制file start_app.sh
   

   如果是DOS格式，输出会包含"with CRLF line terminators"

2. 使用cat -v显示不可见字符：

   bash复制cat -v start_app.sh
   

   Windows换行符会显示为^M$，Unix换行符只显示$

3. 使用hexdump查看原始字节：

   bash复制hexdump -C start_app.sh | head
   

   CRLF会显示为0d 0a，LF只显示0a

3. 解决方案与实操步骤

3.1 方法一：使用vim转换格式

对于已经上传到Linux服务器的文件，最直接的解决方法是使用vim进行格式转换：

1. 使用vim打开脚本文件：

   bash复制vim start_app.sh
   

2. 进入命令模式（按ESC键）

3. 输入以下命令设置文件格式：

   code复制:set fileformat=unix
   

4. 保存并退出：

   code复制:wq
   

注意：vim中也可以使用简写命令:set ff=unix。如果想查看当前文件格式，可以使用:set ff?命令。

3.2 方法二：使用dos2unix工具

Linux系统通常预装了dos2unix工具，专门用于转换文件格式：

1. 安装dos2unix（如果尚未安装）：

   bash复制# Ubuntu/Debian
   sudo apt-get install dos2unix
   
   # CentOS/RHEL
   sudo yum install dos2unix
   

2. 转换文件格式：

   bash复制dos2unix start_app.sh
   

3. 验证转换结果：

   bash复制file start_app.sh
   

   应该显示"ASCII text"，而不是"with CRLF line terminators"

3.3 方法三：使用sed命令处理

如果没有dos2unix工具，可以使用sed命令删除CR字符：

bash复制sed -i 's/\r$//' start_app.sh

这个命令会原地修改文件（-i选项），将所有行尾的\r字符替换为空。

3.4 方法四：Windows端使用Notepad++转换

如果文件还在Windows系统上，可以使用Notepad++进行预处理：

1. 用Notepad++打开脚本文件
2. 查看右下角状态栏，会显示当前换行符格式（如DOS/Windows）
3. 点击"编辑" → "文档格式转换" → "转换为Unix(LF)格式"
4. 保存文件后再上传到Linux服务器

4. 预防措施与最佳实践

4.1 Git配置自动转换

对于使用Git管理的项目，可以配置自动换行符转换：

1. 全局配置（推荐）：

   bash复制git config --global core.autocrlf input
   

   这样在Windows上检出时转换为CRLF，提交时转换为LF

2. 或者针对特定仓库：

   bash复制git config core.autocrlf input
   

3. 还可以在项目根目录添加.gitattributes文件：

   code复制* text=auto
   *.sh text eol=lf
   

4.2 编辑器配置

开发时应在编辑器中设置默认使用Unix换行符：

• VS Code：设置"files.eol"为"\n"
• Sublime Text：在状态栏点击换行符显示，选择"Unix"
• IntelliJ IDEA：设置 → Editor → Code Style → Line separator → Unix and macOS (\n)

4.3 文件权限问题

除了换行符，还要确保脚本有可执行权限：

bash复制chmod +x start_app.sh

否则会报"Permission denied"错误，而不是换行符相关的错误。

4.4 跨平台开发建议

1. 尽量在Linux环境下直接编写和编辑脚本
2. 如果必须在Windows上操作，使用支持换行符转换的编辑器
3. 在CI/CD流程中添加文件格式检查步骤
4. 重要脚本上传前用dos2unix预处理

5. 扩展知识：其他相关文件格式问题

5.1 编码问题

除了换行符，文件编码也可能导致类似问题：

1. UTF-8 with BOM：某些Windows编辑器会添加BOM头

   bash复制# 移除BOM头
   sed -i '1s/^\xEF\xBB\xBF//' script.sh
   

2. 非UTF-8编码：确保脚本使用UTF-8无BOM编码

5.2 行尾空格问题

行尾的空格也可能导致脚本执行异常：

bash复制# 删除所有行尾空格
sed -i 's/[[:space:]]*$//' script.sh

5.3 不同shell的差异

不同的shell对换行符的容忍度不同：

• bash：严格，会报错
• zsh：相对宽松，但也不推荐使用CRLF
• dash：与bash类似

6. 实际案例与排错流程

6.1 典型错误场景重现

1. 在Windows上创建脚本：

   bash复制echo "echo Hello World" > test.sh
   

2. 上传到Linux服务器后执行：

   bash复制bash test.sh
   

   报错：test.sh: line 1: $'\r': command not found

6.2 系统化排错步骤

当遇到脚本执行报错时，建议按以下步骤排查：

1. 检查脚本是否有执行权限：ls -l script.sh
2. 检查文件格式：file script.sh或cat -v script.sh
3. 检查脚本语法：bash -n script.sh
4. 逐行调试：bash -x script.sh
5. 检查环境变量：env与脚本中使用的变量是否匹配

6.3 复杂脚本的调试技巧

对于复杂的脚本，可以：

1. 在脚本开头添加set -x启用调试模式
2. 使用trap命令捕获信号和错误
3. 添加详细的日志输出
4. 使用shellcheck工具进行静态检查：

   bash复制shellcheck script.sh
   

7. 自动化检测与修复方案

7.1 使用pre-commit钩子

在Git仓库中添加pre-commit钩子，自动检查文件格式：

1. 安装pre-commit：

   bash复制pip install pre-commit
   

2. 创建.pre-commit-config.yaml：

   yaml复制repos:
   - repo: https://github.com/pre-commit/pre-commit-hooks
     rev: v4.4.0
     hooks:
     - id: mixed-line-ending
       args: [--fix=lf]
   

3. 安装钩子：

   bash复制pre-commit install
   

7.2 CI/CD流水线集成

在持续集成流程中添加文件格式检查：

yaml复制# .gitlab-ci.yml示例
check_script_format:
  script:
    - git ls-files -z '*.sh' | xargs -0 dos2unix --info
    - if [ $? -ne 0 ]; then echo "Found DOS line endings"; exit 1; fi

7.3 自定义校验脚本

编写简单的校验脚本：

bash复制#!/bin/bash

check_files() {
    local files=$(find . -type f -name "*.sh")
    local has_error=0
    
    for file in $files; do
        if file "$file" | grep -q "CRLF"; then
            echo "ERROR: $file contains CRLF line endings"
            has_error=1
        fi
    done
    
    return $has_error
}

check_files || exit 1

8. 高级话题：深入理解换行符历史

8.1 换行符的历史渊源

不同操作系统使用不同换行符的原因可以追溯到早期的计算机和打字机：

• Unix/Linux：使用LF（\n），源自Multics操作系统
• Windows：使用CRLF（\r\n），源自DOS，继承自CP/M
• 经典Mac OS：使用CR（\r），源自早期的Apple系统

8.2 现代系统的处理方式

现代工具和语言运行时通常能智能处理换行符：

• Python：open()函数的newline参数控制换行符处理
• Java：System.lineSeparator()返回平台相关的换行符
• C：标准库函数在不同平台上有不同的换行符处理

8.3 网络协议中的换行符

许多网络协议明确规定使用CRLF：

• HTTP/1.1：头部字段用CRLF分隔
• SMTP：命令和响应使用CRLF
• FTP：控制连接使用CRLF

这也是为什么Web开发中经常需要处理CRLF换行符。