Reverse 10f and 10g so sort passes these tests.

diff --git a/tests/sort/Test.pm b/tests/sort/Test.pm
index 6ed76420247a70f031c20eec469ba0b54c4ca746..bde59268d3438b7391ad781aae0a389f26539a5a 100755 (executable)
--- a/tests/sort/Test.pm
+++ b/tests/sort/Test.pm
@@ -87,8 +87,11 @@ use strict;
 # An even simpler example demonstrating the bug.
 ["10e", '-k 1.2,1.2', "ab\nba\n", "ba\nab\n", 0],
 #
-["10f", '-t : -k 1.3,1.3', ":ab\n:ba\n", ":ab\n:ba\n", 0],
-["10g", '-k 1.4,1.4', "a ab\nb ba\n", "a ab\nb ba\n", 0],
+# The way sort works on these inputs (10f and 10g) seems wrong to me.
+# See May 30 ChangeLog entry.  POSIX doesn't seem to say one way or
+# the other, but that's the way all other sort implementations work.
+["10f", '-t : -k 1.3,1.3', ":ab\n:ba\n", ":ba\n:ab\n", 0],
+["10g", '-k 1.4,1.4', "a ab\nb ba\n", "b ba\na ab\n", 0],
 #
 # Exercise bug re using -b to skip trailing blanks.
 ["11a", '-t: -k1,1b -k2,2', "a\t:a\na :b\n", "a\t:a\na :b\n", 0],