GNU comm 清单对账：两个文件都有apple，为什么仍要先统一排序规则
比较两份导出的对象清单，常见需求是找出仅在左边、仅在右边以及两边都有的名称。comm能直接生成这三类结果，但它依赖输入有序；把未经整理的两份文件直接交进去，可能得到错误诊断，也可能留下不该继续使用的部分输出。一次可靠对账，需要先固定集合含义和排序条件。
本例在Linux、Bash 5.2.37与GNU coreutils 9.7实跑。固定小样本由printf生成，进程替换提供只读输入，不创建或改写业务文件。LC_ALL=C统一排序与字符比较环境；脚本需要Bash，不能直接当作通用sh脚本运行。
AI生成的概念示意图：两列有序卡片汇入三个清晰托盘，分别呈现左侧独有、右侧独有与共同卡片；不是真实软件界面或运行截图。
完整程序与实际输出
保存为demo.sh，执行bash demo.sh。代码与输出分列如下。
#!/usr/bin/env bash
export LC_ALL=C
left() { printf '%s\n' pear apple apple; }
right() { printf '%s\n' plum apple; }
printf '%s\n' '[three columns, | is a display separator]'
comm --output-delimiter='|' <(left | sort -u) <(right | sort -u)
printf '%s\n' '[only left]'
comm -23 <(left | sort -u) <(right | sort -u)
printf '%s\n' '[common]'
comm -12 <(left | sort -u) <(right | sort -u)
if comm --check-order <(left) <(right) > /dev/null 2>&1; then
printf 'unsorted status=0\n'
else
printf 'unsorted status=%s\n' "$?"
fi本次实际标准输出：
[three columns, | is a display separator] ||apple pear |plum [only left] pear [common] apple unsorted status=1
从三个输出位置读懂结果
本次左侧输入有pear和两个apple，右侧有plum和apple。先经sort -u后，完整输出依次是两个竖线前缀的apple、没有前缀的pear和一个竖线前缀的plum。三种位置对应共同项、左独有项和右独有项；顺序仍按比较规则推进，并非先打印完左边才打印右边。
默认分隔符是制表符，本例用GNU扩展--output-delimiter改成竖线，只为方便在网页上观察。竖线不是输入内容，也不是名称的一部分。实际名称可能含分隔符时，不能只凭这张可视化输出再次拆列，应按已知格式或直接选择需要的输出列。
减号后的数字表示隐藏哪几列
-23隐藏第二和第三列，所以only left只输出pear；-12隐藏第一和第二列，所以common只输出apple。选项描述的是抑制列，而不是选择列，刚使用时很容易反过来记。可以用本例三个已知名称做冒烟测试，避免把共同项当成待删除对象。
comm正常完成时退出零，与两份清单是否相同无关。若程序需要回答“是否完全一致”，还应检查两侧独有结果是否为空，不能只看退出码。对账结果若进一步驱动写操作，更应先展示数量和样本，确认比较键确实代表同一种对象。
排序和去重是两项不同决定
本例使用sort -u，明确把重复名称视为同一个集合成员。因此左侧两个apple最终只占一个位置。如果业务需要检查出现次数，这个预处理就会丢掉关键信息；应保留次数，或者先生成名称与计数再比较。不要为了让输出看起来干净就默认去重。
排序端与比较端还必须使用一致的语言环境。示例统一LC_ALL=C，避免一端按某语言排序、一端按另一规则读取。使用数值排序或忽略大小写排序也不能随意接给默认comm，因为比较规则可能不同；先确认两端认可的有序关系一致。
乱序不能靠关闭检查来修复
最后一次故意省略排序并启用--check-order，得到状态一。为使示例输出不带临时文件描述符路径，该次诊断被重定向丢弃，程序只展示状态；实际工具链应保留诊断。发现乱序后，不应继续使用已经产生的部分结果，更不应加--nocheck-order来隐藏问题。
这里的进程替换很适合小型演示，但真实导出可能在生产阶段失败。父命令成功并不自动证明每个后台生产器成功，稳妥流程应先完成导出、验证状态和条数，再对经过验证的文件排序与比较。本文只证明固定内存样本的集合对账，不提供分布式快照一致性保证。
参考资料与验证记录
官方资料核验于2026年10月3日。本次完整程序退出码为0，标准错误为空。
