Bug 25953 - ls listing is no longer the Unix standard 'capitals first'
ls listing is no longer the Unix standard 'capitals first'
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-04 01:06 EST by Geoff Lane
Modified: 2007-04-18 12:31 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-02-04 06:39:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Geoff Lane 2001-02-04 01:06:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1 i686)


ls now lists out files and directories in the order AaBbCc. etc instead of
[A-Z],[a-z]. This departs from every Unix system that I've ever been on.
There also does not appear to be a 'make output correct' switch or anything
according to the man page. PLEASE - this is way to basic of a Unix concept
to change.

Reproducible: Always
Steps to Reproduce:
1.type 'ls -1' (in this example)

Actual Results:  
bin/
com/
dnetc/
docs/
downs/
evolution/
fm/
fm-991230.tar.gz
gscite135.tgz
hellfire
hinv
isos/
iso.url
jakarta-ant-bin.tar.gz
linux/
Load2alpha4/
Load2alpha4.zip
mozilla/
mp3/
News/
ns_imap/
nsmail/
postfix-20001217-2.i386.rpm
python/
rkit.tar.bz2
src/
sylpheed-0.4.61-1.i386.rpm
tomcat


Expected Results:  
Load2alpha4/
Load2alpha4.zip
News/
bin/
com/
dnetc/
docs/
downs/
evolution/
fm/
fm-991230.tar.gz
gscite135.tgz
hellfire
hinv
isos/
iso.url
jakarta-ant-bin.tar.gz
linux/
mozilla/
mp3/
Comment 1 Geoff Lane 2001-02-04 01:29:23 EST
This has to do with a 'fix' for ls to handle LANG settings. Prior to the beta,
LANG was set to 'C' (LANG=C) and now it's to en_US (LANG=en_US).

While I understand why (technicaly) it's happening, I'm still not sold. :)
Comment 2 Bernhard Rosenkraenzer 2001-02-04 06:38:56 EST
POSIX requires that sorting respects locales.
If you don't like it, export LC_COLLATE=C.
Comment 3 Geoff Lane 2001-02-04 16:10:18 EST
I think a note to this effect should be put somewhere in the docs then since
this is the first time ls has ever behaved this way - and since GNU ls is the
only POSIX compliant ls in the world (that I've seen). Basically I think a lot
of people will freak out about this kind of thing (as I did).
Comment 4 Graham Hudspith 2001-02-12 08:34:35 EST
Please, please, please document this "feature" somewhere where it is easy to
find! I HATE this new feature and quickly want to go back to the old (i.e. the
way everyone else does it) sort-order. Neither 'man ls' or 'info ls' supplied
me with any clues. Only by finding this bug-report have I got the information
that I need.

You shouldn't need to be an expert on Posix (who cares about that anyway) just
to use 'ls'.

My least favourite feature: 'ls -a' ignores the '.' when sorting, instead of
putting all '.' files at the beginning ...
Comment 5 P. Beltrani 2001-02-14 16:54:52 EST
OK, so the behavior is "NOTABUG".  However, I too was unable to find out about
this one by checking the more common sources, i.e. man, info and scanning the
NEWS and README for fileutils.  I would like to suggest info about this one be
included somewhere prominent before it becomes a FAQ.

Comment 6 Adam Thompson 2001-06-06 22:46:56 EDT
[Yes, I know I'm cross-posting. Tough.  This is ludicrous.]

Sorry.  Anything that *BREAKS* scripts after an upgrade IS NOT A FEATURE.

I don't **CARE** if it's POSIX-compliant behaviour, it is inappropriate 
behaviour for an out-of-the-box install.

Maybe that means making the default locale "C" again instead of en_US or 
en_whatever, since I don't recall any way to select the C locale during install.

...like I really needed another excuse to switch to BSD instead of upgrading a 
dozen RedHat customers to 7.1.  Much as I dislike "for historical reasons" 
showing up in the manpage, /bin/ls is critical enough to way too many scripts 
to change DEFAULT behaviours.

(Besides - since when does "." get ignored during collation?  It has a position 
in any collation order.  Maybe before alphas maybe after, but I don't expect 
collation to simply IGNORE characters it doesn't feel like sorting.)
Comment 7 Anne Mahoney 2001-07-20 16:00:19 EDT
I agree;  this has to be documented, and should ideally be corrected.  Perhaps
an optional --posix switch to force this non-standard, untraditional, confusing,
script-breaking, unintuitive behavior?
Comment 8 Need Real Name 2001-07-23 09:45:21 EDT
This IS a bug.  The default behavior has changed.  It breaks scripts.
Someone tries to justify it as "POSIX"?  Probably brought to you by
the same anal jerks that like "--help" instead of the traditional "-?"
for command summaries.  No respect for traditions that made Unix great!
Comment 9 Jim Meyer 2001-12-14 17:46:37 EST
I'm on-board with the rest of these folks -- this should *at least* be
documented heavily; it changed the default function of a basic tool to be
counter to that of every other *nix.

I'm normally on RH's side re: introducing change in order to get us to accept
it. This was disappointing.

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