[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $(sort) - what is "lexical order"? (was RE: Follow-up)

From: Paul Smith
Subject: Re: $(sort) - what is "lexical order"? (was RE: Follow-up)
Date: Tue, 19 Jul 2011 19:02:51 -0400

Please don't reply only to me: discussions belong on the mailing lists.

On Tue, 2011-07-19 at 15:32 -0400, Rob Holbert wrote:
> The key in that definition is "depends on their first letter", not
> "the capitalization of their first letter". But in any event, if you
> don't have a clear definition for Lexical, then that's probably a big
> clue it should not be in the manual. Otherwise, the definition would
> have to mention case. So, using a sort function to provide an unsorted
> list does not sound reasonable to me. Especially when the UNIX command
> line does it right, which is quite odd because I thought the kernal
> was built with make and gcc. Hmmm. Well, maybe somebody ought to get
> coherent on what it does mean instead of reiterating the obvious.

I think there's some misunderstanding of how things really work shown by
this paragraph.  When I use sort on MY command line, it sorts the same
way that GNU make does:

~$ (echo "aardvark"; echo "Zebra") | sort

This is exactly what I'd expect from my UNIX command line tools, because
I've configured my environment to use the built-in sorting order (which
was the only sorting order for much of the history of UNIX), ASCII.

You've configured your environment to use a different sorting order,
which is fine.  The ability to show directory listings, etc. using the
user's personal sorting order preferences is a great enhancement from
when UNIX was originally created.

But it's not at all obvious that having a tool like make follow the
user's wishes here is the right thing to do.

> I would not really expect to find Zebra before a bear in an index? The
> only use for a sorted list is to quickly identify the presence or
> absence of an item by quickly scanning the list. (i.e. Damn why is
> lcd.o not present in the build?) . If not for this, what useful
> purpose does the broken sort serve?

If you understand the sorting order used by make, it's no more or less
difficult to determine whether a file is missing than any other sort
order.  You simply have to look with the other lowercase filenames and
see if it's there.  The sort is not broken.  It's not random; that would
be silly.  It's just not what you're used to.

Consider another scenario: make uses your sorting preferences, and you
run a build and it fails.  You send the log to me and I'm looking at it,
but I use different sorting preferences.  Now I'm confused by your log
because the sorting order is different and I can't find things.  Or,
your build fails because of a subtlety related to the sorting order, but
I can't help you as things work fine for me because I use a different

Having a completely deterministic sorting order is a good thing, for a
build system.  Any ordering which is modified by the user's environment
is by definition not deterministic.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]