Thomas Habets <[EMAIL PROTECTED]> writes: > They may be the same number, but they sure aren't treated as equal > (sort-order equal) by sort. sort -n gives "3 3.0 3.000" every time > here, no matter the input order. As does "3 03 3".
That is because ties are broken at the end by a last-resort textual comparison. Use "sort -s" to disable this. For example: $ printf '3\n03\n3\n' | sort -ns 3 03 3 > So what's your point? Are you refering to what would happen if you'd > combine a -n sort with -R? Yes. > Or should a random permutation merge all equal values? Only if the ordinary sort would merge the equal values (i.e., if the -u option is specified). > Does sort currently merge them, and are you saying the randomization > has to be on the merged results? Yes, I'm saying that randomization should be orthogonal to the other options, and should work well and sensibly with them all. > Can you give an example of permutaded input that does *not* give the same > output? ... if that is what you mean. (excluding randomization here) Sure: $ printf '03\n3\n3\n' | sort -ns 03 3 3 > Does your example still work if the input is: > a b c d b b d > sorts to: > a b c d > b d > b > then randomize to: > c b d a > b d > b > => > c b b b d d a > > That's not what my patch does, so are you saying that is the right thing to > do? Yes, that's what I was thinking of, given the same seed. > why should they randomize to the same output just because they > have the same seed and are a permutation of eachother? Because it's a sort program. :-) Seriously, though, I don't know how this new feature will combine with all the other features of "sort", if it's not some type of feature that can be explained as a sort. _______________________________________________ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils