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

[Oleg Moskalenko]

> -----Original Message-----
> 
> > 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.
> 
> 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 combination. 
I can list some, but I cannot promise to catch all of them. It would be enormous 
work. 

> 
> > If some old scripts are relying on buggy behavior
> > (and I hope they are not) then the old scripts must be fixed. Period.
> 
> 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 compatible with" 
in a clean POSIX-compliant system.

> 
> > The system cannot grow replicating the old bugs.
> 
> 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 expected.
For example, a common complain is about a situation like that: 
try run a trivial command like " $ ls -l /usr/bin | env LANG=en_US.UTF-8 sort -n -k 5" 
and see what it yields for the old BSD/GNU sort. I suspect that when you are talking about 
the old sort compatibility you are really do not know what you are talking about.
Once you start digging, you prospective may change.

> 
> > All system scripts that I've seen are using pretty basic sort
> features.
> 
> 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 implementation.

> 
> > 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).
> 
> So here's one to add to your regression test. I use the following to
> sort IPv4 addresses in a list:
> 
> sort -n -t . -k 1,1 -k 2,2 -k 3,3 -k 4,4
> 
> 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 
in the trivial cases. I think that 99% of users will never see the difference 
between the old sort and the new sort - for a usual non-expert usage 
the two are almost always compatible. Second, do you really think that I need 
lecturing which use cases to test ?

> 
> > 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.
> 
> Please list all of those explicitly.

see above.

> 
> > The new BSD sort program
> > is compatible with the new GNU sort, a much cleaner program than the
> old GNU sort.
> 
> 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 
reasons of better performance and compatibility.

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