Bug 55251

Summary: ls POSIX compliance disturbs normalcy
Product: [Retired] Red Hat Linux Reporter: Neil McNeight <mcneight>
Component: fileutilsAssignee: Bernhard Rosenkraenzer <bero>
Status: CLOSED NOTABUG QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: teg
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2001-10-31 06:11:45 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Restores normalcy to ls, and adds '-P, --posix' flags for occasional trips to Bizarro world (with mfn standing for mother-f**king normal) none

Description Neil McNeight 2001-10-28 09:55:08 UTC
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):


How reproducible:
Always

Steps to Reproduce:
1. type 'ls -al' at any prompt
2.
3.
	

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
letters.

Additional info:

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.

Comment 1 Neil McNeight 2001-10-28 09:57:59 UTC
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)

Comment 2 Trond Eivind Glomsrxd 2001-10-29 19:36:15 UTC
The way it sorts "." is weird, but case insensitivity should be preserved.

Comment 3 Bernhard Rosenkraenzer 2001-10-30 12:08:41 UTC
If you don't like the way POSIX systems should sort things, don't use a case 
insensitive, dot-ignoring locale.

Add

LC_COLLATE=C

or

LANG=C

to /etc/sysconfig/i18n



Comment 4 Neil McNeight 2001-10-31 06:11:38 UTC
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:

static int
compare_name (const struct fileinfo *file1, const struct fileinfo *file2)
{
  register int temp = 0;

  if (!isalpha(file1->name[0]) && isalpha(file2->name[0]))
  {
    temp = -1;
  }
  else if (isalpha(file1->name[0]) && !isalpha(file2->name[0]))
  {
    temp = 1;
  }
  else
  {
    temp = strcoll (file1->name, file2->name);
  }

  return temp;

}

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.

Comment 5 Bernhard Rosenkraenzer 2001-11-07 23:43:10 UTC
Just had a talk with the standards watchers; they say the current behavior is 
correct and must not be changed.
Use LC_COLLATE=C.