Date: Thu, 12 Aug 2004 16:33:34 +1000 From: Tim Robbins <tjr@freebsd.org> To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/contrib/gnu-sort - Imported sources Message-ID: <20040812063334.GA79720@cat.robbins.dropbear.id.au> In-Reply-To: <200408120537.i7C5bkIs005791@repoman.freebsd.org> References: <200408120537.i7C5bkIs005791@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 12, 2004 at 05:37:46AM +0000, Tim J. Robbins wrote: > tjr 2004-08-12 05:37:46 UTC > > FreeBSD src repository > > src/contrib/gnu-sort - Imported sources > Update of /home/ncvs/src/contrib/gnu-sort > In directory repoman.freebsd.org:/tmp/cvs-serv5599 > > Log Message: > Import of GNU sort from coreutils CVS (trimmed) This brings in a few POSIX conformance fixes that change behaviour significantly enough that we would not want to make them after branching RELENG_5. From the ChangeLog file (excerpted): 2004-08-10 Paul Eggert <eggert@cs.ucla.edu> * src/sort.c (die, xfopen, mergefps, first_same_file, merge): A null file arg means standard output. (main): "-o -" means to write to a file named "-", not to standard output. 2004-04-25 Paul Eggert <eggert@twinsun.com> Fix POSIX-conformance bug: "sort -k 3,3.5b" is supposed to skip leading blanks when computing the location of the field end; it is not supposed to skip trailing blanks. Solaris 8 "sort" does conform to POSIX. Also fix the documentation to clarify this and related issues. The only other significant user-visible change is this performance fix: 2004-05-13 Paul Eggert <eggert@cs.ucla.edu> Improve performance of `sort -m' on large files, at the cost of making some contrived examples unsafe. POSIX allows this optimization. Performance problem reported by Jonathan Baker in <http://mail.gnu.org/archive/html/bug-coreutils/2004-05/msg00071.html>. Tim
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040812063334.GA79720>