From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 16:05:13 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 960D91065670; Wed, 27 Jun 2012 16:05:13 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) by mx1.freebsd.org (Postfix) with ESMTP id 2CBE88FC0C; Wed, 27 Jun 2012 16:05:13 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.77,483,1336363200"; d="scan'208";a="29628410" Received: from sjcpmailmx01.citrite.net ([10.216.14.74]) by FTLPIPO01.CITRIX.COM with ESMTP/TLS/RC4-MD5; 27 Jun 2012 12:04:50 -0400 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.73]) by SJCPMAILMX01.citrite.net ([10.216.14.74]) with mapi; Wed, 27 Jun 2012 09:04:50 -0700 From: Oleg Moskalenko To: 'Doug Barton' Date: Wed, 27 Jun 2012 09:04:50 -0700 Thread-Topic: [HEADS-UP] BSD sort is the default sort in -CURRENT Thread-Index: Ac1USWUX7JYWBXz9SyiXYp0W0yozlQAMbLBQ Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA28AEB72@SJCPMAILBOX01.citrite.net> References: <4FEAA280.2070705@FreeBSD.org> <4FEAA599.9070107@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB6D@SJCPMAILBOX01.citrite.net> <4FEAC5B1.30104@FreeBSD.org> <031222CBCF33214AB2EB4ABA279428A3012CA28AEB71@SJCPMAILBOX01.citrite.net> <4FEAD5B8.2090301@FreeBSD.org> In-Reply-To: <4FEAD5B8.2090301@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Current , Gabor Kovesdan Subject: RE: [HEADS-UP] BSD sort is the default sort in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 16:05:13 -0000 > -----Original Message----- >=20 > > But I do not agree with you that we have to reproduce the old sort > bugs. > > It makes no sense and I am not going to do that. Absolutely not. >=20 > That isn't what I said. What I asked is for you to *test* the existing > sort vs. the new one, and to report where the behavior is different. > That's a very basic part of any sort of "replace a core utility" > project > such as this one. The problem is that the sort program has huge number of possible options co= mbination.=20 I can list some, but I cannot promise to catch all of them. It would be eno= rmous=20 work.=20 >=20 > > If some old scripts are relying on buggy behavior > > (and I hope they are not) then the old scripts must be fixed. Period. >=20 > With respect, that's not your decision (or mine for that matter). We > first need the data, then as a project we decide how many old bugs we > want to be compatible with, if any. This is an incorrect approach. You never want "old bugs we want to be compa= tible with"=20 in a clean POSIX-compliant system. >=20 > > The system cannot grow replicating the old bugs. >=20 > And the project cannot grow if we lose users due to gratuitous > differences in core utilities. There are users that we are loosing because the utilities do not work as ex= pected. For example, a common complain is about a situation like that:=20 try run a trivial command like " $ ls -l /usr/bin | env LANG=3Den_US.UTF-8 = sort -n -k 5"=20 and see what it yields for the old BSD/GNU sort. I suspect that when you ar= e talking about=20 the old sort compatibility you are really do not know what you are talking = about. Once you start digging, you prospective may change. >=20 > > All system scripts that I've seen are using pretty basic sort > features. >=20 > The system scripts are only a tiny fraction of how FreeBSD users use > sort. This is even stronger emphasizes the need in a standard-compliant implement= ation. >=20 > > In the basic > > area, the old sort and the new sort are 100% compatible. The > incompatibilities are > > in more complex areas (numeric sorts and unusual key-based sorts). >=20 > So here's one to add to your regression test. I use the following to > sort IPv4 addresses in a list: >=20 > sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4 >=20 > When used with GNU sort that will sort a list of IPv4 addresses into a > humanly-recognizable numeric order. Please ensure that this works the > same way with the new sort. First, this is a pretty trivial use case. Don't expect anything different=20 in the trivial cases. I think that 99% of users will never see the differen= ce=20 between the old sort and the new sort - for a usual non-expert usage=20 the two are almost always compatible. Second, do you really think that I ne= ed=20 lecturing which use cases to test ? >=20 > > I am actually tested the new sort against the old GNU sort. There are > some incompatibilities. > > All of them are due to the bugs of the old GNU sort. >=20 > Please list all of those explicitly. see above. >=20 > > The new BSD sort program > > is compatible with the new GNU sort, a much cleaner program than the > old GNU sort. >=20 > That's good, but not really relevant to the users of what we have in > the > base now. I bet many of them are installing the new GNU coreutils exactly for the=20 reasons of better performance and compatibility. >=20 > I realize that these questions may seem discouraging, but they need to > be answered. It would have been nice if Gabor had posted a "we think > we're ready to make the new sort the default, any last concerns?" > message, but deal with where we are at and move forward. He actually did. You probably missed the messages. Thanks, Oleg