Re: mtree output sorting

[Alan Barrett <apb%cequrux.com@localhost>]

On Mon, 06 Apr 2009, Joerg Sonnenberger wrote:
> On Mon, Apr 06, 2009 at 03:51:41PM +0200, Alan Barrett wrote:
> > I resently changed "mtree -C" to sort its output into the same order
> > used by "mtree -c".  The sort order is that used by strcmp(), except
> > that directories sort after non-directories.
> 
> I don't like that last part. It means the result can change in the face
> of symlinks to directories.

Yes, if a directory changes to a symlink, or vice versa, then the sort
order will change, in addition to entries below that directory appearing
or disappearing.  This will not happen during a build.sh build.  Is it
an issue in other scenarios?

I do think that the sort order from "mtree -c" should match the sort
order from "mtree -C", so if the order is bad then it should be changed
in both places.

> > 1) find(1) also has a sort option, "find -s", but that uses
> >    strcoll(3), not strcmp(3).  Should mtree use strcoll(3) for
> >    sorting?
>
> Do we want it to be locale-sensitive? We don't have collation support
> ATM, but it is a missing feature.

Well, we can call strcoll(), even if that has missing features.
build.sh sets LC_ALL=C anyway so this doesn't affect repeatable builds.
I don't have much of an opinion about whether strcoll is better than
strcmp here; it's just that I noticed the use of strcoll in find(1) and
wondered about consistency.

Any comment on the whether it's OK to add a new "-S" option to control
whether or not output from mtree -C is sorted?

--apb (Alan Barrett)