被遗忘的Linux命令fold：把超长日志按宽度折成易读行

前阵子帮朋友排查一台 Linux 服务器上的日志，日志里每条请求都混在一行里，动辄三四千字符，终端刷得毫无阅读性。若是只看尾部倒还好，可那次要提取某个时间片里的状态码，我用 grep 和 awk 折腾了半天。后来同事敲了一句 fold -w 120 error.log | less，问题立刻变简单。我那时候意识到：fold 这个被遗忘在 Linux 常用命令边缘的工具，很多时候能省下大把时间。

fold 是 Unix/Linux 自带的文本处理命令，作用是把输入文件或标准输入中的每一行，按指定宽度折成多行，然后输出到标准输出。它不会修改原文件，也不会对文本做字段提取、按语义排版，它做的事情只有一件：一行太长时，在合适位置插入换行。这件看似简单的事，恰恰是长日志、超长 JSON、base64 字符串和定宽记录文件处理的痛点。这篇文章适合三类人：正在系统学 Linux 常用命令的新手，想在常用命令之外补充冷门工具箱的运维，以及在文本处理场合想从 grep/sed/awk 里跳出来的人。

1. 长行文本是隐形炸弹：真正需要 fold 的场景

1.1 日志系统把一切写成单行之后，终端变得不好用了

很多后端日志系统虽然支持结构化，但落盘时仍然习惯用 JSON 一行一条。为了便于后续采集，日志框架会把这些字段压在一行，最长可达几千甚至几万字符。你在终端里 cat，屏幕上全是乱窜的软换行；想用 less 往后翻，翻到的也是同一行逻辑内容。想切换到别的工具按列提取，又很难确定一行到底在哪个位置结束。

我第一次系统地用 fold，就是处理这种情况。有个同事把线上报错日志导出来，单行是一条 Java 异常的完整堆栈。异常信息本身还好，后面跟了 50 多行调用栈，全部被日志采集端塞进一个字符串字段。此时 grep 能搜到关键字，但想看关键字之后的全部内容时几乎没法看。运行下面的命令之后，输出条理就清楚多了：

bash复制fold -w 200 exception.log | less

每一段被硬性折成不超过 200 列的独立行，再用 less 浏览就舒服很多。严格来说，fold 不会增加任何新信息，但它把“物理行”重新组织了一遍，让终端不再以自己的软换行逻辑干扰你。这个“物理行重排”的概念很重要，因为很多看似能用 awk 解决的问题，一旦换成 fold 的思路，脚本会简单得多。

1.2 fold 不是 fmt，也不该拿 cut 替代

新手最常见的误解是：fold 跟 fmt 差不多，或者可以直接用 cut -c 来做。其实它们属于三种不同的心智模型。我专门整理了一个对比，方便你一次记住差别：

fold 处理的最小单位是行，它对每一行独立操作，按宽度断开后输出，不考虑段落上下文，也不合并之前的行。fmt 则会先把文本看成段落，再合并短行、调整空格和换行，目的是让版面更好看。cut -c 是按列区间挑内容，通常只输出每行指定部分，不负责把剩余部分折到下一行。awk 的问题则在于它重心在字段重组，如果只是想让行变短，用 awk 去处理 substr 反而要先计算偏移，很容易出错。

所以请记住：当目标是“一个超长内容，我不想丢字，只是希望它按固定宽度变成多行”时，fold 才是语义最匹配的命令。我见过不少人在脚本里用 sed 去插入换行符，最后不得不处理各种偏移，而 fold 一行命令就做完了。

2. 我用 fold 之前先搞明白的参数机制

2.1 默认宽度 80 列从哪来，-w 的真实含义又是什么

不是所有用户都注意到，fold 在无参数时会默认按 80 列折叠。这个数值来自早期终端和打印纸的物理限制，放到今天已经很少适合直接用。因此实际使用中，-w 几乎必带。它的意思是：输出的每行最多占 width 列。如果某个输入行本身没超过这个宽度，该行就原样输出，fold 不会强行补空格。

一个最直观的例子：

bash复制printf '1234567890\n' | fold -w 4

输出是：

text复制1234
5678
90

这个例子说明 fold 没有别的花活，纯粹在列边界处断开。可是“列”不一定等于“字符数”或“字节数”，这是很多人的第一个盲区。对于纯 ASCII 文本，三者相等；一旦文本里出现 tab、退格符或多字节字符，差异就很明显。比如 tab 单独占一个字节，但终端默认会把 tab 移动到下一个 8 列边界，所以在一行中间插入 tab 会占 1 到 8 列不等。fold 按列宽计数时会把 tab 的展开