Bug 55251 - ls POSIX compliance disturbs normalcy
Summary: ls POSIX compliance disturbs normalcy
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
(Show other bugs)
Version: 7.2
Hardware: All Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-10-28 09:55 UTC by Neil McNeight
Modified: 2007-04-18 16:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-10-31 06:11:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
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 09:57 UTC, Neil McNeight
no flags Details | Diff

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: 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:

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

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.





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

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