[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: mtree output sorting
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)
Main Index |
Thread Index |