Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 49170 - Sort order is broken in non-"C" locales
Sort order is broken in non-"C" locales
Product: Red Hat Linux
Classification: Retired
Component: mc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jonathan Blandford
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-07-16 10:42 EDT by Dmitry Bolkhovityanov
Modified: 2013-04-02 00:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-07-16 10:49:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dmitry Bolkhovityanov 2001-07-16 10:42:08 EDT
Description of Problem:
MC presents list of files sorted in a wrong way (similar to bugs #18074 and
First, it sorts files case-insensitively even when shouldn't, second, more
important, dot-files are mixed with usual ones, while dot-files should go

How Reproducible:

Steps to Reproduce:
1. Set locale to en_US: export LANG=en_US
2. Start MC and a) Set the Options|Config|"show Hidden files" to On and
"miX all files" to Off, b) in the "Sort order" dialog set to "Name" and
"case sensitive" to On (this is the default configuration).
3. Go to some dir which contains both normal and dot-files (e.g. ".bashrc",
".cshrc" and "bear").

Actual Results:

Expected Results:

Additional Information:
This is because of a bug in strcoll(), which a) sorts *always*
case-insensitively and b) ignores non-alphanumeric characters (hence the
dot-files problem).

While (a) is arguable, (b) is definitely a bug, and, in fact, a bug in
glibc (it affects "ls" too).

At least the dot-files problem (more annoying than case-sensitivety, BTW)
can be fixed with a trivial patch (against 4.5.54):

--- src/dir.c.orig      Tue Jan 30 23:46:04 2001
+++ src/dir.c   Wed Jul 11 21:09:41 2001
@@ -97,8 +97,8 @@
 sort_name (const file_entry *a, const file_entry *b)
-    int ad = MY_ISDIR (a);
-    int bd = MY_ISDIR (b);
+    int ad = MY_ISDIR (a) * 2 + (a->fname[0] == '.');
+    int bd = MY_ISDIR (b) * 2 + (b->fname[0] == '.');
     if (ad == bd || mix_all_files)
        return string_sortcomp (a->fname, b->fname) * reverse;
Comment 1 Jonathan Blandford 2001-07-16 17:32:35 EDT
Forwarded to the mc maintainer
Comment 2 Stowe Davison 2002-03-21 17:56:22 EST
Here, I guess is another instance of this.  sort considers the following
list to be "sorted":

If you set env var LC_COLLATE to C, the list really does get sorted.

But whatever the default collating sequence is, apparently it sees no
difference between './' and ''.  I can see that one or the other might
come first, depending on the collating sequence chosen.  But the fact
that the "default" behavior of sort is to ignore the difference is 
pretty sordid, in my opinion.

I see the bug has been referred to the maintainer.  I hope it gets 
fixed.  I find the problem in RH 7.0, 7.1, 7.2.
Comment 3 Dmitry Bolkhovityanov 2002-03-22 00:56:50 EST
Yes, the behaviour is absolutely unusable, but it seems that noone cares.
The root of the problem is a lacking POSIX standard: strcoll() was designed to
satisfy *distionaries*, but there's a need in a separate function (e.g.
strnofoldcoll()) to be used to sort directory listings, computer book indices,

Right after reporting to bugzilla.redhat.com, I've filed a bug on Glibc, but the
response was "we don't care" (see

Note You need to log in before you can comment on or make changes to this bug.