Bash 错误消息重定向

Begindev 编辑部 March 30, 2026

在 Bash 中重定向错误消息是编写健壮且易于管理的脚本的一项关键技能。虽然标准输出（stdout）负责处理命令成功执行的结果，但标准错误（stderr）才是程序发送诊断消息、警告和报错的地方。

将这两个数据流分离开来，能够让你对不同类型的命令输出进行更精细的控制。这对于系统日志记录、代码调试以及构建不间断的自动化流程来说是绝对必要的。

1. 深入理解标准错误 (stderr)

在默认情况下，Bash 中执行的每一个命令都有可能产生两种类型的输出流：

标准输出 (stdout): 这是程序写入其正常、成功执行结果的地方。它由文件描述符 1 表示。
标准错误 (stderr): 这是程序写入错误消息、警告或诊断信息的地方。它由文件描述符 2 表示。

默认情况下，stdout 和 stderr 都会直接将它们的输出显示在终端屏幕上。然而，将它们分开对于提高脚本的可靠性和可维护性至关重要。

举个例子：如果你的脚本在处理一个日志文件，它将处理结果输出到 stdout，但同时遇到了几个无权读取的文件并把错误输出到了 stderr。如果把 stderr 重定向到一个独立的错误日志文件中，你就能轻松排查问题，而不会让普通的输出结果被报错信息搅得一团糟。

我们来看看简单的 ls 命令列出文件的表现：

如果你运行 ls existing_file.txt（存在的文件），内容（文件名）会发送到 stdout。
如果你运行 ls non_existent_file.txt（不存在的文件），报错信息 "ls: cannot access 'non_existent_file.txt': No such file or directory" 会发送到 stderr。

2. 基础错误重定向

重定向 stderr 最主要的方法是使用文件描述符 2，紧跟着重定向操作符 >。

2.1 将 stderr 重定向到文件

要仅将命令的错误输出发送到特定文件，请使用 2> 加上文件名。

# 示例 1: 仅重定向 stderr
# 'ls' 命令尝试列出一个不存在的文件。
# 它的报错信息会被发送到 'error.log'，而不是显示在终端上。
ls non_existent_file.txt 2> error.log

# 如果 'existent_file.txt' 存在，它的输出依然会进入 stdout (显示在终端)。
ls existent_file.txt non_existent_file.txt 2> error.log
# 终端上会出现 "existent_file.txt"。
# 而关于 "non_existent_file.txt" 的报错则被悄悄写入了 error.log。

# 验证 error.log 的内容
cat error.log

在这个例子中，2> 确保了只有来自文件描述符 2（标准错误）的数据被重定向。标准输出（文件描述符 1）除非被显式重定向，否则依然会打印在控制台上。

2.2 将 stdout 和 stderr 分别重定向到不同的文件

在实际应用中，将成功的输出和报错输出分开存放到不同的文件是非常常见的做法。

# 示例 2: stdout 进一个文件，stderr 进另一个文件
# 该命令尝试列出 existing.txt (成功) 和 non_existent.txt (失败)。
ls existing.txt non_existent.txt 1> output.txt 2> error.log

# 检查 output.txt
cat output.txt
# 预期结果: existing.txt

# 检查 error.log
cat error.log
# 预期结果: ls: cannot access 'non_existent.txt': No such file or directory

在这里，1> output.txt 将 stdout 送往了 output.txt，而 2> error.log 将 stderr 送往了 error.log。1> 和 2> 的书写顺序通常无关紧要，但为了代码易读性，建议保持一致的习惯。

3. 合并标准输出与标准错误

有时候，你可能希望把 stdout 和 stderr 都送到同一个目的地，比如一个统一的综合日志文件。有几种方法可以实现。

3.1 将 stderr 重定向到 stdout 的位置

2>&1 结构的作用是将文件描述符 2 (stderr) 重定向到文件描述符 1 (stdout) 当前所指向的位置。

极其重要的一点是：如果你打算将两者都写入文件，2>&1 必须放在 1>（或简写为 >）的后面，因为 Bash 是从左到右解析重定向的。

# 示例 3: 将 stdout 和 stderr 合并重定向到一个文件
# 尝试列出一个存在的文件和一个不存在的文件。
# 成功的输出和报错消息都会进入 'all_output.log'。
ls existing.txt non_existent.txt > all_output.log 2>&1

# 验证内容
cat all_output.log
# 预期结果:
# existing.txt
# ls: cannot access 'non_existent.txt': No such file or directory

解析这个过程：

> all_output.log 首先将 stdout (1) 指向了文件 all_output.log。
2>&1 接着将 stderr (2) 指向了当前 stdout (1) 所指的地方，也就是 all_output.log。

反面教材： 如果你写成了 2>&1 > all_output.log，它的意思是：先让 stderr 跟着 stdout 走（此时 stdout 还是终端屏幕），然后把 stdout 指向文件。结果就是：只有正常信息进了文件，错误信息依然会在终端上弹出来！

3.2 合并重定向的简写语法 (Bash 4+)

为了方便起见，Bash 4 及更高版本引入了一个非常简洁的简写符号 &>，用于将 stdout 和 stderr 一并重定向到同一个文件。

# 示例 4: 使用 '&>' 合并重定向
# 这与 '> all_output.log 2>&1' 的效果完全相同
ls existing.txt non_existent.txt &> combined_output.log

# 验证内容
cat combined_output.log

在需要将所有信息汇总到同一目的地时，这种简写方式因为代码更简洁，通常是首选。

4. 重定向到 Linux 的“黑洞”：/dev/null

/dev/null 是类 Unix 系统中的一个特殊设备文件，常被称为“空设备”或“数据黑洞”。任何被重定向到 /dev/null 的数据都会被直接丢弃，相当于让它们凭空消失。

当你想要抑制某些输出（特别是你不关心的错误消息，或者预期会发生的错误）时，这个特性极其有用。

4.1 静默丢弃 stderr

# 示例 5: 抑制错误信息
# 'ls non_existent_file.txt' 产生的报错会被直接丢弃。
ls non_existent_file.txt 2> /dev/null

# 如果命令还有正常的 stdout，正常内容依然会显示在终端。
ls existing.txt non_existent_file.txt 2> /dev/null
# 预期结果: 终端只显示 existing.txt，你看不到任何报错信息。

这在执行某些可能产生无害警告的命令时，或者脚本故意尝试一项可能会失败但无需通知用户的操作时非常有价值。

4.2 同时丢弃 stdout 和 stderr

# 示例 6: 彻底静默（抑制所有输出）
# 无论成功还是报错，你都不会看到任何输出，也不会留下任何日志。
ls existing.txt non_existent_file.txt > /dev/null 2>&1

# 或者使用更现代的简写:
ls existing.txt non_existent_file.txt &> /dev/null

这常用于后台静默任务（不需要任何交互式反馈），或者当你仅仅只想通过 $? 检查命令的退出状态码，而不想让其输出弄脏屏幕时。

5. 追加重定向的输出

就像处理标准输出一样，你可以使用 2>> 将 stderr 的内容追加 (append) 到一个已存在的文件末尾。这对于创建持续记录的错误日志非常实用。

# 示例 7: 将 stderr 追加到日志文件
echo "--- 脚本启动 ---" >> application_errors.log
date >> application_errors.log

# 第一次运行产生错误
ls non_existent_file_1.txt 2>> application_errors.log

# 第二次运行产生另一个错误
ls non_existent_file_2.txt 2>> application_errors.log

# 验证内容
cat application_errors.log
# 预期结果:
# --- 脚本启动 ---
# <当前日期和时间>
# ls: cannot access 'non_existent_file_1.txt': No such file or directory
# ls: cannot access 'non_existent_file_2.txt': No such file or directory

这允许你随着时间的推移不断积累错误信息。对于长时间运行的进程或每日自动执行的定时任务 (Cron jobs) 来说，将所有问题集中追踪在同一个地方是至关重要的。

6. 综合实战：在系统备份脚本中处理错误

在第 1 章中，我们介绍了一个自动化系统管理任务的实战案例。一个非常典型的任务就是备份文件。

假设我们有一个脚本试图将一个列表中的文件复制到备份目录中。如果其中有些文件在脚本运行前被删除了，cp 命令就会生成 stderr 报错。我们应该捕获这些报错并记录到错误日志中，同时不中断脚本的运行。

场景: 备份脚本遍历文件列表。有些文件可能不存在了。

#!/bin/bash
BACKUP_DIR="/tmp/backup_$(date +%Y%m%d%H%M%S)"
ERROR_LOG="backup_errors.log"
SOURCE_FILES=("file1.txt" "file2.txt" "non_existent_file.txt" "another_file.txt")

echo "开始备份流程..."

# 创建几个测试用的假文件
touch file1.txt file2.txt another_file.txt
mkdir -p "$BACKUP_DIR"

# 在错误日志中添加一个带时间戳的分割线
echo "--- 备份错误日志 $(date) ---" >> "$ERROR_LOG"

for file in "${SOURCE_FILES[@]}"; do
    # 尝试复制，并将报错信息追加到错误日志中
    if cp "$file" "$BACKUP_DIR" 2>> "$ERROR_LOG"; then
        echo "成功备份: $file"
    else
        echo "备份失败: $file (详细原因请查看 $ERROR_LOG)"
    fi
done

echo "备份流程结束。请检查 $ERROR_LOG 确认是否有异常。"

# 清理测试文件和目录
rm -f file1.txt file2.txt another_file.txt
rm -rf "$BACKUP_DIR"

代码解析:

cp "$file" "$BACKUP_DIR" 2>> "$ERROR_LOG": 这一行是核心。它尝试复制文件。如果 cp 遇到错误（例如文件不存在），它的错误消息会被追加到 backup_errors.log 中。
if 语句检查 cp 的退出状态码。成功则打印成功消息；失败（非零状态码）则打印失败提示并引导用户去查看错误日志。
这种模式使得脚本在遇到个别文件备份失败时依然能继续运行完成后续任务，同时又保留了清晰的错误追踪记录。这正是自动化系统脚本应有的健壮性。