Do not consider newline to be part of a line when comparing lines

in `sort' and `comm'.  POSIX.2 requires that we consider newline,
but this is a bug in the spec and the bug will likely be fixed.

1 files changed, 6 insertions, 15 deletions

diff --git a/doc/textutils.texi b/doc/textutils.texi
index 2e8eabb99..d83fb6184 100644
--- a/doc/textutils.texi
+++ b/doc/textutils.texi
@@ -2129,10 +2129,12 @@ or global options are specified, @samp{-s} has no effect.
 GNU @code{sort} (as specified for all GNU utilities) has no limits on
 input line length or restrictions on bytes allowed within lines.  In
 addition, if the final byte of an input file is not a newline, GNU
-@code{sort} silently supplies one.  A line's trailing newline is part of
-the line for comparison purposes; for example, with no options in an
-@sc{ascii} locale, a line starting with a tab sorts before an empty line
-because tab precedes newline in the @sc{ascii} collating sequence.
+@code{sort} silently supplies one.  A line's trailing newline is not
+part of the line for comparison purposes.@footnote{@sc{posix}.2-1992
+requires that the trailing newline be part of the comparison, and some
+@code{sort} implementations obey this requirement, but it is widely
+considered to be a bug in the standard and the next version of
+@sc{posix}.2 will likely remove this requirement.}
 
 Upon any error, @code{sort} exits with a status of @samp{2}.
 
@@ -2350,17 +2352,6 @@ sort -nr
 @end example
 
 @item
-Ignore trailing newlines when comparing lines,
-so that empty lines always sort first.
-
-@example
-# "$newline" is a single newline character.
-newline='
-'
-sort -t "$newline" -k 1,1
-@end example
-
-@item
 Sort alphabetically, omitting the first and second fields.
 This uses a single key composed of the characters beginning
 at the start of field three and extending to the end of each line.