当未提供 --stable 选项时， sort -n 是否可预测地处理关系？如果有，怎么做？

Question

这里看起来像3在两行之后的空格打破了数字排序并让字母排序开始，所以11< 2：

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

在man sort，我读

       -s, --stable
              stabilize sort by disabling last-resort comparison

这意味着没有 -s一个不得已的比较是完成（之间的关系，因为-s不影响非关系）。

所以问题是：这种最后的比较是如何完成的？如果有必要回答问题，欢迎参考源代码。

这个答案 Unix从实验中推断出关系的排序是按字典顺序排列的。

标准/POSIX 是否对此有任何说明？

Answer 1

这里看起来像两行 3 之后的空格打破了数字排序并让字母排序开始

sort -n不是sort -n -k1,1 -k2,2。sort -n将整行（不是字段！）解释为一个数字，比如atoi("3 11")给出3。然后对这些数字进行排序。因为sort_them(atoi("3 11"), atoi("3 2"))是未排序的，因为两者都是 number 3，最后的比较排序开始了。

这种最后的比较是如何完成的？

这个想法是将整行进行比较，就像通过strcmp或相似（即strcoll）。由于1之前说到2，strcmp("3 11", "3 2")排序3 11为第一。不考虑任何选项，-n不考虑。

如果有必要回答问题，欢迎参考源代码。

实际上，xmemcoll0在 GNU sort 中，在比较 (struct line const *a, struct line const *b)中的coreutils sort.c#L2653 中考虑整理，并且memcmp在LC_COLLATE未设置时作为后备。

我在OpenBSD中看到那种很somehwere周围的OpenBSD /排序/ coll.c＃L528 str_list_coll（结构bwstring * STR1，结构sort_list_item ** SS2） ，而且在list_coll_offset（） ，其中，如果所有的键比较等于top_level_str_coll被称为刚刚梳理了整个线。

标准/POSIX 是否对此有任何说明？

如果“这个”指的是稳定排序和最后的比较，那么肯定。让我们从POSIX 排序重点复制整个段落：

比较应基于从每一行输入中提取的一个或多个排序键（或者，如果未指定排序键，则为直到但不包括终止的整行），并应使用当前语言环境。如果此整理顺序没有对所有字符进行总排序（请参阅 XBD LC_COLLATE），则应使用 POSIX 语言环境的整理顺序进一步逐字节比较任何同等整理的输入行。

和

鼓励实现对同等整理的行执行推荐的进一步逐字节比较，即使这可能会影响效率。如果当前语言环境的整理序列没有所有字符的总排序（如果实现提供了一种查询方式）或仅在语言环境名称存在时执行附加比较，则可以通过仅执行附加比较来减轻对效率的影响与 LC_COLLATE 类别相关联的名称中有一个“@”修饰符（因为没有“@”修饰符的区域设置应该具有所有字符的总排序 - 请参阅 XBD LC_COLLATE）。请注意，如果实现提供了一个稳定的排序选项作为扩展（通常是 -s），则在指定此选项时不应执行额外的比较。