Sort order bug in GNU sort

[Luke Hutchison]

Hi,

The following is the output of GNU sort (without any switches) on an
unsorted file.  Numerous errors (of the same variety) seem present in the
ordering.  I am using coreutils-7.2-4.fc11.x86_64.  Problems are shown in
red.

Additionally, there probably needs to be a switch added to sort that uses
the entire line as the sort key, not blank-to-non-blank transition (the
default), so that lines are always compared character-by-character in the
same character position, so that corresponding characters are always
compared within the same sort field, and so that sorting always creates the
correct lexicographical ordering of lines based on line content, not based
upon any interpretation of separator boundary.  (I think parsing
blank/non-blank separator boundaries does not always produce the same
thing?)

Please confirm that you have received this email, and let me know if I need
to file this bug elsewhere.

Thanks,
Luke Hutchison

--

sampleId-1000,1.0
sampleId-100,0.125
sampleId-1002,0.25
sampleId-1002,0.5
sampleId-1004,0.25
sampleId-1005,0.0625
sampleId-1005,0.125
sampleId-1006,0.125
sampleId-1007,0.125
sampleId-1008,1.0
sampleId-1010,0.0625
sampleId-101,0.0625
sampleId-1010,1.0
sampleId-1011,0.0625
sampleId-1011,0.125
sampleId-1012,0.125
sampleId-1012,0.25
sampleId-1013,1.0
sampleId-1014,1.0
sampleId-1015,1.0
sampleId-1017,1.0
sampleId-1018,0.0625
sampleId-1018,0.125
sampleId-1019,1.0
sampleId-102,0.0625
sampleId-1020,1.0
sampleId-102,0.5
sampleId-1023,1.0
sampleId-1024,0.125
sampleId-978,1.0
sampleId-979,1.0
sampleId-980,1.0
sampleId-98,1.0
sampleId-981,0.0625
sampleId-981,0.25
sampleId-982,1.0
sampleId-984,0.125
sampleId-984,0.5
sampleId-985,0.0625
sampleId-985,0.5
sampleId-986,1.0
sampleId-987,1.0
sampleId-988,1.0
sampleId-990,1.0
sampleId-99,1.0
sampleId-991,0.25
sampleId-992,0.125
sampleId-992,0.25
sampleId-995,0.0625
sampleId-995,0.25
sampleId-996,0.125
sampleId-996,0.25
sampleId-997,0.125
sampleId-997,0.5