Bug 55251 - ls POSIX compliance disturbs normalcy
ls POSIX compliance disturbs normalcy
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-28 04:55 EST by Neil McNeight
Modified: 2007-04-18 12:37 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-10-31 01:11:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Restores normalcy to ls, and adds '-P, --posix' flags for occasional trips to Bizarro world (with mfn standing for mother-f**king normal) (3.27 KB, patch)
2001-10-28 04:57 EST, Neil McNeight
no flags Details | Diff

  None (edit)
Description Neil McNeight 2001-10-28 04:55:08 EST
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 04:57:59 EST
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 14:36:15 EST
The way it sorts "." is weird, but case insensitivity should be preserved.
Comment 3 Bernhard Rosenkraenzer 2001-10-30 07:08:41 EST
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 01:11:38 EST
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 18:43:10 EST
Just had a talk with the standards watchers; they say the current behavior is 
correct and must not be changed.
Use LC_COLLATE=C.


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