Re: Collating order

[Bob Proulx]

Ole Laursen wrote:
> Apparently, the way ls sort the file names does not work with a
> localised sorting order. For instance, with a en_US locale, I get:

Actually your issue is that ls and sort *do* work with a localised
sorting order.  If it did not then you would always get C/POSIX
sorting.

> I would expect the behaviour of the LANG=C locale. According to a
> knowledgeable guy on the libc-locales mailing list, the behaviour is a
> feature of the localised sorting mechanism:

That's correct.  In the old days ls and sort were not locale aware and
always sorted in US-ASCII collating sequence.  But now ls and sort are
locale aware and sort using the user specified collating sequence
using the strcoll(3) library routine.  Usually this is controlled by
the LANG variable.  But the LC_COLLATE and LC_ALL in that order will
override the previous variable.

> I guess the problem is that the dot has a different meaning in the
> context of file names so "ls" should try to do something clever like
> splitting the extension from the basename and sort the basenames
> first.

The dot has no special meaning in filenames.  It is no different than
any other character.  The only two special characters are / and \0,
neither of which can appear in filenames.

By convention filenames with a leading dot are hidden files.  In very
new versions of ls you can control the pattern of hidden files such as
to include files starting with a comma as being hidden.

You can control the sorting order in ls and sort through the use of
the LANG, LC_COLLATE and LC_ALL variables.  If you don't want
internationalization then you can unset all of those or set the
appropriate ones to C.  All of unset or set to C or set to POSIX would
set a standard C/POSIX locale.

See your system and other standards documentation for how it reacts in
the presence of locales.

  http://www.opengroup.org/onlinepubs/007908799/xcu/sort.html
  http://www.opengroup.org/onlinepubs/007908799/xbd/locale.html

Hope this helps,
Bob