> I would like to report what I think is a bug in ls.
>
> Bug Synopsis: ls does not honor collating sequence of selected locale
Thank you for your very detailed and well presented bug report. You
did a great job with that. Since most of the bug reports we get are
really terrible yours came as a breeze of fresh air. I wanted to say
thanks for that.
> Description:
> ls always sorts its output using the C locale's collating sequence.
> That is all uppercase names are listed first before lowercase ones.
>
> When LANG is set to some locale other than C, (a good example is
> en_US), the collating sequence should be case insensitive -- ie. a
> name that starts with 'a' should come before a name that starts
> with 'B'.
This is actually very humorous since if you search the archives you
will find that the number one bug report we get is that when LANG is
set to en_US that sorting -is- case insensitive when they don't want
it to be. This is mostly due to Redhat setting LANG=en_US in
/etc/profile.d/lang.sh and the user not knowing anything about
localization and so the case insensitivity is a surprise to them.
Also I believe the en_US tables are buggy for other reasons.
> the ls command does not follow this. Instead, no matter what
> locale I select, the sorting is still based on the C locale's
> collating sequence
I believe that ls -does- respect locale data. Since you tested with
different values of LANG I can only assume that one of the higher
priority environment variables were set which would override LANG.
Please check for the presence of LC_anything such as LC_ALL.
> To reproduce the bug:
Very nicely done.
Here is a standard mailing list answer for when people report the
OPPOSITE problem. Please apply it in REVERSE and see if it works in
your case.
This is due to the fact that you or your vendor have set environment
variables that direct the program to use locale specific sorting
tables which do not sort as you expect. You or your vendor have
probably set environment variables like LANG, LC_ALL, or LANG to
en_US. There appears to be a problem with that table on some systems
which is not part of the GNU program but part of your vendor's system
release.
Unset them, and then set LC_ALL to POSIX.
# If you use bash or some other Bourne-based shell,
export LC_ALL=POSIX
# If you use a C-shell,
setenv LC_ALL POSIX
and it will then work the way you expect because it will use a
different set of tables.
See the standards documentation for more information on the locale
variables with regards to ls.
http://www.unix-systems.org/single_unix_specification_v2/xcu/ls.html
> Distribution: Debian GNU/Linux 2.2 (potato)
> % ls --version
> ls (GNU fileutils) 4.0l
While being stable Potato is getting a little dated to the point that
it can be difficult to remember what the behavior was on 4.0l, etc.
Perhaps updating a newer version from Woody or Sid would be
appropriate. Here is some other peripheral information that you may
find helpful.
The latest released version is
ftp://ftp.gnu.org/pub/gnu/fileutils/fileutils-4.1.tar.gz
The latest testing version is
ftp://alpha.gnu.org/gnu/fileutils/fileutils-4.1.5.tar.gz
The FAQ for the core utilities answers the most frequently asked
questions asked on the mailing lists and newsgroups.
http://www.gnu.org/software/fileutils/doc/faq/
Bob
_______________________________________________
Bug-fileutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-fileutils
