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;
Forwarded to the mc maintainer
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.
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).