From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
Description of problem:
Entering the ls command gives a freakish dance-interpretation of what
should be a standard Unix file listing. Dot files are now alphabetically
interspersed with regular files, with no distinction being made between
uppercase and lowercase letters.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. type 'ls -al' at any prompt
Actual Results: A wormhole opened up and transported me to some form of
Bizarro parallel universe where order does not apply.
Expected Results: A standard Unix file listing. Dot files first, then
files starting with capital letters, then files starting with lowercase
I realize that this is not a new bug, and it has apparently been discussed
ad nauseum. However, I have seen no patches available to "fix" the problem,
so I decided to create one, for better or worse. Attached patch builds just
fine with fileutils-4.1, and applies just fine to the fileutils package.
Created attachment 35282 [details]
Restores normalcy to ls, and adds '-P, --posix' flags for occasional trips to Bizarro world (with mfn standing for mother-f**king normal)
The way it sorts "." is weird, but case insensitivity should be preserved.
If you don't like the way POSIX systems should sort things, don't use a case
insensitive, dot-ignoring locale.
I repectfully disagree.
While I don't have access to the POSIX standard, I would like to hope it was not
the intention of its creators to break over 1 billion seconds of established
behavior. I believe that changing locale, even temporarily, is a rather
backwards way of looking at the problem. If this is official RedHat policy, then
perhaps a warning should be placed when choosing a locale, to alert people that
a locale other than C or POSIX may break the established usage of common utilities?
If I use the sort command, then I might want it to skip over any non-alpha
characters and sort alphabetically. But with ls, I expect .files to come before
regular files. It's an established pattern, and breaks a lot of documentation as
well as some code (bad code, but code nevertheless).
To allow for any non-alpha files (including # and ~ files) to be placed at the
top of a directory listing, and still allow the use of a normal locale, I
suggest the following:
compare_name (const struct fileinfo *file1, const struct fileinfo *file2)
register int temp = 0;
if (!isalpha(file1->name) && isalpha(file2->name))
temp = -1;
else if (isalpha(file1->name) && !isalpha(file2->name))
temp = 1;
temp = strcoll (file1->name, file2->name);
Since isalpha() is a locale aware function, under all circumstances non-alpha
characters are placed in the directory listing first, followed by a
case-insensitive listing of files after that.
I'm not trying to be a stick in the mud, or I'd just stick with strcmp() and be
done with it. But change just for the sake of change has never made me very happy.
Just had a talk with the standards watchers; they say the current behavior is
correct and must not be changed.