sort -n未启用--stable时并列项处理是否可预测？相关规则及POSIX规范

实际观测到的异常现象 #

执行如下shell命令时，由于两行文本的首列数值均为3，按照预期的数值排序逻辑，本该让第二列数值更小的3 2排在前面，实际输出却出现了11排在2之前的结果：

$ echo -e '3 2\n3 11' | sort -n
3 11
3 2

根据sort手册的公开说明，-s/--stable选项的核心作用是禁用并列项的兜底比较以实现稳定排序，这也就意味着：不加-s选项时，只要出现指定排序键相等的情况，程序就会触发额外的兜底比较逻辑；这个逻辑不会干预本身排序键就存在大小差异的条目顺序。

兜底比较的实现逻辑 #

从GNU sort的源码实现层面来看，这个兜底比较的规则非常明确：

• 当按照用户指定的排序规则（比如-n代表数值排序）对比两个条目、得出“排序键相等”的判定后，程序不会直接保留条目原输入顺序，而是启动整行文本的逐字节字典序比较作为最终的排序依据。
• 对应到上面的测试用例：两个行的第一列数值都是3，按照-n的数值规则判定为排序键相等，此时触发兜底流程逐字节对比整行内容——空格后的第一个字符，3 11行是'1'，3 2行是'2'，按照ASCII字典序'1' < '2'，因此3 11会被判定为更小值排在前面，和实际观测的输出完全匹配。
• 手动加上-s选项后，程序会在判定排序键相等时直接终止比较，保留条目在原输入中的相对顺序，也就是实现了稳定排序的效果：

  $ echo -e '3 2\n3 11' | sort -n -s
  3 2
  3 11
  

通过多组对照测试也能验证，GNU sort在并列项场景下的兜底规则确实为整行字典序比较，和源码实现的逻辑完全匹配。

POSIX标准的相关约束 #

针对这个并列排序的场景，POSIX标准并没有做强制的统一行为要求：

• 标准仅明确了基础规则：当用户指定的排序键对比结果出现相等情况时，条目的最终先后顺序可以由具体的sort实现自行定义，也就是说不同系统的sort工具，完全可以采用不同的兜底逻辑处理并列项。
• 标准同时对稳定排序场景做了强制要求：如果用户显式指定了稳定排序（对应-s选项），那么排序键相等的条目必须严格保留输入时的相对顺序，这也是所有符合POSIX规范的sort实现必须满足的要求。

正是因为标准允许自定义兜底逻辑，GNU sort选择了整行字典序的兜底方案，才会出现开头测试里那种看起来反直觉的排序结果。

内容的提问来源于stack exchange，提问作者Enlico