Warning: file_get_contents(/data/phpspider/zhask/data//catemap/8/sorting/2.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Sorting sort-k#.#n不同于sort-k#.#-n?_Sorting_Unix - Fatal编程技术网

Sorting sort-k#.#n不同于sort-k#.#-n?

Sorting sort-k#.#n不同于sort-k#.#-n?,sorting,unix,Sorting,Unix,[编辑后添加了-b,我已经尝试过了,但没有效果] 我有一个文件,括号里有一列数字,我想 诸如此类: x (10) x (11) x (1) x (2) 我认为sort-b-k2.2n可以工作。但事实并非如此。 但是我发现,sort-b-k2.2-n确实有效,生成了 期望输出 x (1) x (2) x (10) x (11) 有人能解释为什么吗?我知道-n将所有列视为数字 (不仅仅是被选中的那些),但我很惊讶这会带来不同。 我真的认为-k2.2n会对第二列进行排序 从数字上来说,从第二个位置

[编辑后添加了
-b
,我已经尝试过了,但没有效果]

我有一个文件,括号里有一列数字,我想 诸如此类:

x (10)
x (11)
x (1)
x (2)
我认为
sort-b-k2.2n
可以工作。但事实并非如此。 但是我发现,
sort-b-k2.2-n
确实有效,生成了 期望输出

x (1)
x (2)
x (10)
x (11)
有人能解释为什么吗?我知道
-n
将所有列视为数字 (不仅仅是被选中的那些),但我很惊讶这会带来不同。 我真的认为
-k2.2n
会对第二列进行排序 从数字上来说,从第二个位置开始,我不知道 理解它为什么不起作用。(尽管排序)的细微差别有所不同 当然可以。)


这是“排序(GNU coreutils)5.93”,如果它有区别的话。[后来,我在另一台装有coreutils 8.5的机器上试用了它,并看到了相同的结果。]

coreutils 5.93真的很旧了。较新版本有一个很好的
--debug
选项,显示字段选择器如何应用于每一行

您遇到的问题是,默认情况下,排序字段拆分包括字段之间的空白,作为以下字段的一部分。因此,在您的例子中,第二个字段是带有前导空格的
“(1)”
,因此
-k2.2
正在选择一个以括号开头的子字符串,该子字符串随后无法识别为数字

您可以通过添加
b
标志来解决此问题<代码>排序-k2.2nb或
排序-k2.2-n-b
应该可以工作

在最近的coreutils(8.23)中,我无法重现您的
sort-k2.2-n
-它的行为与
sort-k2.2n
相同,无法匹配数字,并返回到“整行字符串比较”排序

更新(3):现在我在5.93、8.13和8.23版本中复制了您的结果。对此有一个明确的解释

我的两个建议(
sort-k2.2nb
sort-k2.2-n-b
)都有效。您的
排序-b-k2.2n
没有。在支持
--debug
的版本中,它表示:

$ printf '%s\n' 'x ('{1,2,10,11}')'|sort -k 2.2n -b --debug
sort: using simple byte comparison
sort: leading blanks are significant in key 1; consider also specifying 'b'
sort: key 1 is numeric and spans multiple fields
sort: option '-b' is ignored
x (1)
  ^ no match for key
_____
x (10)
  ^ no match for key
______
x (11)
  ^ no match for key
______
x (2)
  ^ no match for key
_____
$
选项'-b'被忽略
是对所发生情况的解释。只要将一个标志(n)附加到使用
-k
给出的a键规范,该键的所有全局指定标志都将被忽略

coreutils的GNU信息文档清楚地说明了这一点(我用粗体标记了重要部分):

以下选项影响输出行的顺序。它们可以全局指定,也可以作为特定键字段的一部分指定。如果未指定关键字段,则全局选项适用于整行的比较;否则,全局选项将由键字段继承,而键字段本身不指定任何特殊选项。在POSIX之前版本的“排序”中,全局选项只影响后面的键字段,因此可移植shell脚本应首先指定全局选项

(并且
-b
在下面的列表中。)

手册页的措辞不太清楚:

KEYDEF是F[.C][OPTS][,F[.C][OPTS]]表示开始和停止位置,其中F是字段编号,C是字段中的字符位置;两者都是原点1,停止位置默认为直线的端点。如果-t和-b都无效,则字段中的字符从前面空白的开头开始计数。OPTS是一个或多个单字母排序选项[BDFGIMHNRV],它覆盖该键的全局排序选项。如果未指定键,则使用整行作为键

您可以很容易地将其解释为每个单个字母选项仅覆盖同一字母的全局选项。但你错了

问题很清楚(我再次将重要的部分加粗):

以下选项应覆盖默认订购规则。当订购选项独立于任何关键字段规范时,所要求的字段订购规则应全局应用于所有排序键。当连接到特定键(请参见-k)时,指定的订购选项应覆盖该键的所有全局订购选项

唯一稍微不清楚的是,
-b
没有出现在紧跟该段落的列表中。该列表后面只有一句话,介绍了另一个包含
-b
-t
选项的列表,因此您可能会认为
-b
不在“覆盖所有全局排序选项”规则的范围内


毕竟,
-b
不是一个排序选项,而是一个字段拆分选项,当您将其附加到键定义时,可以将其分别应用于开头、结尾或两者。因此,这与其他任何选择都不一样。但至少在GNU实现中,它确实遵循了“覆盖所有全局排序选项”规则。

Coreutils 5.93非常古老。较新版本有一个很好的
--debug
选项,显示字段选择器如何应用于每一行

您遇到的问题是,默认情况下,排序字段拆分包括字段之间的空白,作为以下字段的一部分。因此,在您的例子中,第二个字段是带有前导空格的
“(1)”
,因此
-k2.2
正在选择一个以括号开头的子字符串,该子字符串随后无法识别为数字

您可以通过添加
b
标志来解决此问题<代码>排序-k2.2nb或
排序-k2.2-n-b
应该可以工作

在最近的coreutils(8.23)中,我无法重现您的
sort-k2.2-n
-它的行为与
sort-k2.2n
相同,无法匹配数字,并返回到“整行字符串比较”排序

更新(3):现在我在5.93、8.13和8.23版本中复制了您的结果。对此有一个明确的解释

我的两个建议(
sort