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
