diff options
| -rwxr-xr-x | tests/misc/sort | 27 |
1 files changed, 7 insertions, 20 deletions
diff --git a/tests/misc/sort b/tests/misc/sort index fedbf278f..5bc526a27 100755 --- a/tests/misc/sort +++ b/tests/misc/sort @@ -310,26 +310,13 @@ my @Tests = ["nul-nls", '', {IN=>"\0b\n\0a\n"}, {OUT=>"\0a\n\0b\n"}], # Paul Eggert wrote: -# I tested the revised `sort' against Solaris `sort', and found a -# discrepancy that turns out to be a longstanding bug in GNU sort. -# POSIX.2 specifies that a newline is part of the input line, and should -# be significant during comparison; but with GNU sort the newline is -# insignificant. Here is an example of the bug: -# -# $ od -c t -# 0000000 \n \t \n -# 0000003 -# $ sort t | od -c -# 0000000 \n \t \n -# 0000003 -# -# The correct output of the latter command should be -# -# 0000000 \t \n \n -# 0000003 -# -# because \t comes before \n in the collating sequence, and the trailing -# \n's are part of the input line. +# A previous version of POSIX incorrectly required that the newline +# at the end of the input line contributed to the sort, which would +# mean that an empty line should sort after a line starting with a tab +# (because \t precedes \n in the ASCII collating sequence). +# GNU 'sort' was altered to do this, but was changed back once it +# was discovered to be a POSIX bug (and the POSIX bug was fixed). +# Check that 'sort' conforms to the fixed POSIX, not to the buggy one. ["use-nl", '', {IN=>"\n\t\n"}, {OUT=>"\n\t\n"}], # Specifying two -o options should evoke a failure |