RE: [HEADS-UP] BSD sort is the default sort in -CURRENT

> -----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

_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"