Bug 49170 - Sort order is broken in non-"C" locales
Summary: Sort order is broken in non-"C" locales
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: mc (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Jonathan Blandford
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-07-16 14:42 UTC by Dmitry Bolkhovityanov
Modified: 2013-04-02 04:15 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Dmitry Bolkhovityanov 2001-07-16 14:42:08 UTC
Description of Problem:
MC presents list of files sorted in a wrong way (similar to bugs #18074 and
#18047).
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
first.

How Reproducible:
100%

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:
.bashrc
bear
.cshrc

Expected Results:
.bashrc
.cshrc
bear

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 @@
 int
 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 21:32:35 UTC
Forwarded to the mc maintainer

Comment 2 Stowe Davison 2002-03-21 22:56:22 UTC
Here, I guess is another instance of this.  sort considers the following
list to be "sorted":
./bin/
bin/
./bin/coordConversion
bin/ifpBackup
./bin/ifpIMAGE
bin/ifpInit
./bin/ifpnetCDF
bin/ncdump
./bin/run/
bin/run/

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 05:56:50 UTC
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,
etc.

Right after reporting to bugzilla.redhat.com, I've filed a bug on Glibc, but the
response was "we don't care" (see
http://mail.gnu.org/pipermail/bug-glibc/2001-July/003438.html).


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