《从零手写操作系统 (29)：管道与重定向进阶——命名管道、Here Document与Shell语法扩展》

前言：从"交互式玩具"到"自动化脚本引擎"

在上一章中，我们的Shell拥有了作业控制，成为了一个合格的交互终端。但如果只能手动敲命令，它仍然只是一个"高级计算器"。真正的Unix哲学在于组合与自动化：将多个小工具通过I/O胶水粘合成复杂的数据处理流水线，并将这些流水线固化为可复用的脚本。

本章我们将补齐Shell作为"编程语言"的关键拼图：命名管道（FIFO）让无关进程也能通信；Here Document让脚本内嵌多行文本数据；而更丰富的重定向语法（>>, 2>&1, <&-）则赋予了I/O拓扑任意组合的能力。这三者结合，标志着你的OS从"人机交互界面"正式迈入"可编程计算平台"。

本章里程碑：

• ✅ sys_mknod(FIFO) / sys_mkfifo：内核命名管道支持
• ✅ FIFO语义实现：阻塞open、读写分离、多读者/写者行为
• ✅ Shell Here Document解析：<<EOF ... EOF 语法与临时文件生成
• ✅ 高级重定向：追加(>>)、合并(2>&1)、关闭(<&-)
• ✅ Shell脚本执行器：shebang(#!)检测与解释器递归调用
• ✅ 验证：包含FIFO、here doc和复合重定向的脚本正确运行

---

核心概念：I/O不是"文件操作"，而是"数据流拓扑构建"

FIFO vs Anonymous Pipe：持久化的 rendezvous 点

匿名pipe是父子进程间的临时通道，随fd关闭而消失。FIFO则是文件系统中的一个持久化汇合点 ：任何知道路径的进程都可以打开它，无需亲缘关系。但FIFO的open语义远比普通文件复杂：默认情况下，只读open会阻塞直到有写者打开，只写open会阻塞直到有读者打开。这种"双向等待"确保了通信双方同时就位，避免了向无人读取的管道写入导致SIGPIPE或数据丢失。

⚠️ 关键洞察 ：FIFO的阻塞open不是"bug"，而是同步原语 。它将"建立连接"和"开始通信"合二为一。如果你的实现让open立即返回（像普通文件一样），就必须引入额外的握手协议来确认对端就绪，这违背了FIFO的设计初衷。但也要提供O_NONBLOCK选项，允许服务器程序先以非阻塞方式打开读端，避免在没有客户端时永久挂起。阻塞是默认安全语义，非阻塞是高级优化接口。

Here Document的本质：语法糖包装的临时文件

<<EOF看起来像是"内联输入"，但内核不知道什么是here document。Shell负责将<<EOF和EOF之间的文本提取出来，写入临时文件或pipe，然后将对应fd重定向给目标命令 。这意味着here document的实现完全是Shell层的词法分析+I/O重定向问题，内核只需正常支持read()即可。但这种分层也意味着Shell必须正确处理变量展开（<<EOF展开vs<<'EOF'不展开）、缩进剥离（<<-EOF）等语义细节。

重定向的顺序敏感性

cmd >out 2>&1 和 cmd 2>&1 >out 的结果完全不同。前者先将stdout指向out，再将stderr复制到stdout（即也指向out）；后者先将stderr复制到当前stdout（通常是终端），再将stdout指向out（stderr仍指向终端）。重定向是从左到右依次执行的fd操作序列，每一步都基于前一步修改后的fd表状态。如果Shell把重定向当作无序集合处理，就会产生与POSIX不一致的行为。

---

实战代码

内核FIFO实现

// kernel/fifo.c
#include "vfs.h"
#include "process.h"
#include "waitqueue.h"

typedef struct fifo_inode {
    pipe_buf_t buf;           // 复用匿名pipe的环形缓冲区
    int readers;              // 当前打开的读者数
    int writers;              // 当前打开的写者数
    wait_queue_t read_wait;   // 等待读者的写者队列
    wait_queue_t write_wait;  // 等待写者的读者队列
    spinlock_t lock;
} fifo_inode_t;

// ★ FIFO open：根据mode决定是否阻塞
int fifo_open(inode_t *inode, file_t *file) {
    fifo_inode_t *fifo = (fifo_inode_t *)inode->private_data;
    int is_write = (file->flags & O_ACCMODE) == O_WRONLY;
    int nonblock = (file->flags & O_NONBLOCK);
    
    spin_lock(&fifo->lock);
    
    if (is_write) {
        if (nonblock && fifo->readers == 0) {
            spin_unlock(&fifo->lock);
            return -ENXIO; // POSIX: 非阻塞写端无读者时返回错误
        }
        fifo->writers++;
        // 唤醒可能在等待写者的读者
        wake_up_all(&fifo->write_wait);
        
        // 阻塞等待至少一个读者（非阻塞模式跳过）
        while (!nonblock && fifo->readers == 0) {
            sleep_on(&fifo->read_wait, &fifo->lock);
        }
    } else { // 读端
        fifo->readers++;
        wake_up_all(&fifo->read_wait);
        
        while (!nonblock && fifo->writers == 0) {
            sleep_on(&fifo->write_wait, &fifo->lock);
        }
    }
    
    spin_unlock(&fifo->lock);
    return 0;
}

// ★ FIFO close：更新计数并唤醒对端
int fifo_close(inode_t *inode, file_t *file) {
    fifo_inode_t *fifo = (fifo_inode_t *)inode->private_data;
    int is_write = (file->flags & O_ACCMODE) == O_WRONLY;
    
    spin_lock(&fifo->lock);
    if (is_write) {
        fifo->writers--;
        if (fifo->writers == 0)
            wake_up_all(&fifo->write_wait); // 通知读者EOF
    } else {
        fifo->readers--;
        if (fifo->readers == 0)
            wake_up_all(&fifo->read_wait); // 通知写者SIGPIPE
    }
    spin_unlock(&fifo->lock);
    return 0;
}

// ★ sys_mkfifo系统调用
int sys_mkfifo(const char *path, mode_t mode) {
    // 创建特殊inode，type=S_IFIFO
    inode_t *inode = vfs_create(path, S_IFIFO | (mode & 0777));
    if (!inode) return -EIO;
    
    fifo_inode_t *fifo = kmalloc(sizeof(fifo_inode_t));
    pipe_buf_init(&fifo->buf);
    fifo->readers = fifo->writers = 0;
    init_waitqueue(&fifo->read_wait);
    init_waitqueue(&fifo->write_wait);
    spin_init(&fifo->lock);
    
    inode->private_data = fifo;
    inode->ops = &fifo_file_ops; // read/write/open/close指向fifo_*
    return 0;
}

Shell Here Document解析

// user/shell/parser.c
#include "shell.h"
#include <fcntl.h>
#include <unistd.h>

// ★ 解析 <<DELIM ... DELIM 并返回可读fd
int parse_here_document(const char **input, int quoted_delim) {
    // 提取delimiter
    char delim[64];
    *input = skip_whitespace(*input);
    *input = extract_token(*input, delim, sizeof(delim));
    
    // 收集内容直到匹配delimiter
    char buffer[4096];
    int len = 0;
    const char *line_start = *input;
    
    while (*line_start) {
        const char *line_end = strchr(line_start, '\n');
        if (!line_end) break;
        
        int line_len = line_end - line_start;
        // 检查是否为结束标记（整行精确匹配）
        if (line_len == strlen(delim) && 
            strncmp(line_start, delim, line_len) == 0) {
            *input = line_end + 1;
            break;
        }
        
        // 追加到buffer（简化：实际应动态扩容）
        if (len + line_len + 1 < sizeof(buffer)) {
            memcpy(buffer + len, line_start, line_len);
            len += line_len;
            buffer[len++] = '\n';
        }
        line_start = line_end + 1;
    }
    
    // ★ 创建pipe并将内容写入写端
    int pipefd[2];
    if (pipe(pipefd) < 0) return -1;
    
    write(pipefd[1], buffer, len);
    close(pipefd[1]); // 关闭写端，使读端获得EOF
    
    return pipefd[0]; // 返回读端fd供重定向使用
}

高级重定向与Shebang执行

// user/shell/exec.c
// ★ 应用单个重定向操作（从左到右顺序调用）
int apply_redirection(redir_t *r) {
    switch (r->type) {
        case REDIR_OUT:      // >
            close(r->fd);
            open(r->target, O_WRONLY | O_CREAT | O_TRUNC, 0644);
            break;
        case REDIR_APPEND:   // >>
            close(r->fd);
            open(r->target, O_WRONLY | O_CREAT | O_APPEND, 0644);
            break;
        case REDIR_IN:       // <
            close(r->fd);
            open(r->target, O_RDONLY);
            break;
        case REDIR_DUP:      // 2>&1
            dup2(r->src_fd, r->fd);
            break;
        case REDIR_CLOSE:    // <&- or >&-
            close(r->fd);
            break;
        case REDIR_HEREDOC:  // <<EOF
            close(r->fd);
            dup2(r->heredoc_fd, r->fd);
            close(r->heredoc_fd);
            break;
    }
    return 0;
}

// ★ Shebang检测与解释器递归
int exec_with_shebang(const char *path, char **argv) {
    int fd = open(path, O_RDONLY);
    if (fd < 0) return -1;
    
    char header[256];
    int n = read(fd, header, sizeof(header)-1);
    close(fd);
    
    if (n >= 2 && header[0] == '#' && header[1] == '!') {
        // 解析解释器路径和可选参数
        char *interp = header + 2;
        char *newline = strchr(interp, '\n');
        if (newline) *newline = '\0';
        
        // 去除首尾空格
        while (*interp == ' ') interp++;
        char *space = strchr(interp, ' ');
        
        // 构造新argv: [interpreter] [optional_arg] [script_path] [orig_args...]
        char *new_argv[64];
        int idx = 0;
        new_argv[idx++] = interp;
        if (space) {
            *space = '\0';
            new_argv[idx++] = space + 1;
        }
        new_argv[idx++] = (char *)path;
        for (int i = 1; argv[i] && idx < 62; i++)
            new_argv[idx++] = argv[i];
        new_argv[idx] = NULL;
        
        return execve(interp, new_argv, environ);
    }
    
    // 非shebang文件，尝试直接exec（ELF二进制）
    return execve(path, argv, environ);
}

---

关键细节解析

1. 为什么FIFO的read/write要复用匿名pipe的环形缓冲区？

因为FIFO和匿名pipe的数据流语义完全相同：单向、字节流、有界缓冲、EOF由写端关闭触发。区别仅在于生命周期管理 （文件系统引用vs fd引用）和open同步语义。复用同一套pipe_buf实现避免了代码重复，也保证了两种管道在缓冲大小、部分读写行为上的一致性。但要注意：FIFO的pipe_buf必须在最后一个引用释放时kfree，而匿名pipe在fd关闭时自动回收。

2. 为什么Here Document用pipe而非临时文件？

临时文件方案需要创建、写入、删除文件，涉及三次VFS操作和磁盘I/O（即使有page cache）。Pipe方案完全在内存中完成，且天然支持"边写边读"的流式语义，避免了将整个here doc内容物化到存储介质。更重要的是，pipe不需要文件系统写权限，使得here doc在只读根文件系统或受限环境中也能工作。唯一代价是需要fork或使用异步写入来避免死锁（大here doc可能填满pipe buffer），教学实现中假设here doc小于PIPE_BUF即可同步写入。

3. 为什么Shebang解析必须在用户态而非内核？

因为shebang的解释器路径可能是另一个shebang脚本（如#!/usr/bin/env python3），形成递归链。如果内核处理shebang，就需要在内核中实现路径搜索、权限检查、递归深度限制等逻辑，大幅增加内核攻击面。POSIX将shebang定义为用户态约定 ，内核只负责exec ELF二进制。ld.so或Shell检测到#!后自行递归调用execve，保持了内核的最小可信基。这也是为什么Linux内核虽然实现了binfmt_script，但许多嵌入式OS选择在Shell层处理。

---

调试Checklist：管道与重定向排查

症状	可能原因	排查方法
mkfifo后open永久阻塞	未以对端mode打开/FIFO阻塞语义未实现/O_NONBLOCK未生效	确认一端O_RDONLY另一端O_WRONLY；kprintf fifo_open入口mode和阻塞条件；测试O_NONBLOCK是否返回-ENXIO
FIFO读端收到EOF过早	写端意外关闭/writers计数错误	kprintf fifo_close中的writers--；确认所有写端fd在使用期间保持打开；strace等价追踪open/close配对
Here Document内容为空	delimiter匹配逻辑错/buffer未写入pipe/heredoc_fd未dup2	dump收集的buffer内容和长度；确认write(pipefd1)返回值==len；验证apply_redirection中dup2成功
2>&1 >out stderr未到文件	重定向顺序实现为无序/REDIR_DUP在REDIR_OUT之前执行	确认parser按从左到右顺序构建redir链表；dump apply_redirection调用序列；对比>out 2>&1行为差异
Shebang脚本报ENOEXEC	解释器路径含空格未正确处理/换行符未截断/header读取不足	hexdump shebang行确认\n位置；验证strchr('\n')截断逻辑；测试带参数的shebang如#!/bin/sh -e
>>覆盖而非追加	O_APPEND标志缺失/lseek到末尾后被truncate	确认open flags包含O_APPEND而非O_TRUNC；验证内核O_APPEND实现为原子append-write

🔧 黄金法则 ：I/O重定向调试的终极武器是fd表快照函数 。在Shell的每次重定向前后、子进程exec前、FIFO open/close时，dump当前进程的完整fd表：每个fd号→(inode类型, 偏移量, flags, refcount)。I/O bug几乎总是"某个fd在某个时刻指向了错误的对象"：dup2覆盖了不该覆盖的fd、close遗漏导致fd泄漏、here doc的pipe读端被意外关闭。只有完整的fd拓扑图才能发现这些结构性错误。不要只看命令输出------输出只是fd状态的最终投影，中间态的fd混乱才是根因。

---

本章小结与下一步

今天我们让Shell从"交互终端"进化为"脚本引擎"：

• ✅ 实现了FIFO命名管道，支持跨进程持久化通信
• ✅ Here Document解析将内联文本转化为标准输入流
• ✅ 高级重定向语法支持追加、合并、关闭等fd操作
• ✅ Shebang机制使脚本可自描述解释器，支持递归执行
• ✅ 验证了复合I/O拓扑的正确构建与数据流通

从此，你的操作系统拥有了可编程的I/O组合能力。当你第一次运行一个包含FIFO通信、here doc配置注入和日志重定向的自动化脚本时，你见证的是OS从"人操作的机器"到"机器自己操作的机器"的根本转变。

下一章预告：《环境变量与进程上下文：export/unset与继承语义》

当前的进程缺乏环境块支持，PATH查找、HOME目录、LANG设置等基础功能缺失。下一章将实现envp传递、export/unset命令、以及正确的fork/exec环境继承语义，为你的Shell补上运行时上下文的最后一环。

---

参考资料

• POSIX.1-2017: Named Pipes, Shell Command Language §2.7 Redirection
• Linux Kernel: fs/fifo.c, fs/binfmt_script.c
• GNU Bash Manual: Here Documents, Redirections
• Stevens & Rago, APUE Ch.15.5 FIFOs, Ch.17.4 Environment Variables
• 本系列完整代码：你的GitHub仓库链接（Commit: f1f0h3r）

---

📝 作者注 ：这是《从零手写操作系统》系列的第29篇。I/O重定向和Here Document看似简单，实则是Shell parser复杂度陡增的起点 。词法分析的歧义（<< vs < <）、重定向与管道的优先级、引号嵌套中的delimiter识别，每一个都是corner case地狱。强烈建议先用单元测试验证parser对各种重定向组合的AST生成正确性，再集成到exec流程中。把"词法分析"、"AST构建"、"fd操作执行"分成三个独立可测试模块，是避免在grammar泥潭中迷失的关键纪律。 下一章，我们让进程从"裸执行体"走向"携带上下文的计算单元"！