/bin/ls sorting bug?
das at FreeBSD.ORG
Mon Jun 21 05:44:34 GMT 2004
On Sun, Jun 20, 2004, Scott Mitchell wrote:
> On Sun, Jun 20, 2004 at 09:59:12AM +0100, David Malone wrote:
> > On Sat, Jun 19, 2004 at 11:52:29PM +0100, Scott Mitchell wrote:
> > > On Sat, Jun 19, 2004 at 10:06:01PM +0200, Dimitry Andric wrote:
> > > > Looking through ls source shows that the sorting is done by passing a
> > > > comparison function to fts_open(3). In the case of sorting by
> > > > modification time, the *only* comparison made is of the mtime fields:
> > >
> > > You did see the patch attached to my original post, right? It modifies all
> > > of these comparison functions to sort the two items by name (or reverse
> > > name) in the case that their timestamps are equal.
> > Hi Scott,
> > Could you produce a version of your patch that uses the nanoseconds
> > field too? I produced the one below, but I think the style in your
> > patch was nicer. Also, I wonder if the revblahcmp functions should
> > just call blahcmp with their arguments reversed?
> > David.
> New patch attached that compares against the nanos field as well. It could
> stand a bit of cleaning up to remove the overly long lines.
> I'm not sure I'd want this in the tree unless we also had an option to
> display the nanoseconds - as it stands you could get items apparently
> ordered wrongly, unless you knew the value of their nanos fields. I could
> do that if people thought it would be useful.
Sorting on nanoseconds too is likely to be more confusing than
useful. Even if we use one of the precious few option letters ls
doesn't use already to add a nanosecond display, most people won't
know about it because they don't care about nanoseconds. They
might care when they notice---as you did---that the sort order
isn't what they expected.
Is the point of sorting on nanoseconds to totally order the files
based on modification time?
More information about the freebsd-hackers