[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#373704: sort -k does not count fields the same as gnu sort



severity 373704 critical
found 373704 1:1.1.3-3
thanks

I had meant to look into this much earlier, but unfortunately it slipped 
my mind. Severity critical as this behavior can cause hard to trace 
unpredictable behavior in any script using sort with a delimiter, 
potentially leading to random breakage in unrelated software.

With the following test file:
a c a
b b c
a a b

# sort -k1 test
a a b
a c a
b b c
# sort -k2 test
a a b
b b c
a c a
# sort -k3 test
a c a
a a b
b b c

Conclusion: when testing _without_ delimiter, the sort is correct.

With a slightly modified test file:
a/c/a
b/b/c
a/a/b

# sort -k1 -t/ test
a/a/b
a/c/a
b/b/c
# sort -k2 -t/ test
a/a/b
b/b/c
a/c/a
# sort -k3 -t/ test
a/a/b
b/b/c
a/c/a

Conclusion: when sorting with delimiter on the last field, the 
last-but-one field is sorted instead.

With a leading delimiter in the test file:
/a/c/a
/b/b/c
/a/a/b

# sort -k1 -t/ test
/a/a/b
/a/c/a
/b/b/c
# sort -k2 -t/ test
/a/a/b
/a/c/a
/b/b/c
# sort -k3 -t/ test
/a/a/b
/a/c/a
/b/b/c

Conclusion: with a leading delimiter, the sort is somehow _always_ done on 
the first field.

It looks like sorting with a specific delimiter set is completely broken.
Tests were done inside Debian Installer.

The testcase included in the busybox testsuite seems to work only by 
accident as it is a numeric sort and the last field to be sorted is the 
only numerical data in each line.

Attachment: pgpUcsec1ASHj.pgp
Description: PGP signature


Reply to: