Bug 33141 - ls alphabethical sort does not respect capitalization and starting .
ls alphabethical sort does not respect capitalization and starting .
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2001-03-25 18:04 EST by pogosyan
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-03-25 18:04:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description pogosyan 2001-03-25 18:04:11 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; OSF1 V4.0 alpha)

fileutils-4.0.27-1.   'ls' invoked without options (presumably alphabetical
sort of the output)
is case insensitive.   In addition 'ls -a' mixes together entries with and
without starting '.'

Reproducible: Always
Steps to Reproduce:
1.   Just call  '/bin/ls' on a directory containing files with mixed
capitalization in names

Actual Results:  > /bin/ls -1

Expected Results:  I expect old 'ls' behaviour, when files with names
starting with capitals preceed the rest,
and hidden files shown by 'ls -a' preceed regular.
Comment 1 Bernhard Rosenkraenzer 2001-03-26 07:30:52 EST
This is caused by the fact that ls is locale aware, as required by POSIX.
Not a bug, but a feature.
If you don't like it, export LC_COLLATE=C
(And read the docs ;) )
Comment 2 pogosyan 2001-03-26 11:58:23 EST
Thanks a lot for quick answer !  (Of course I don't like this behaviour, it
breaks what I'm used to, and even few of my poorly written scripts :) )

Regarding the docs: I read man pages before posting - there is no mentioning
of this change in the behaviour.   Neither is in 'info' files, which I just
checked now. May be I missed something, but, to quote from info 'Sorting the
output' section

Sorting the output

   These options change the order in which `ls' sorts the information
it outputs.  By default, sorting is done by character code (e.g., ASCII

Actually I did not find any discussion of enviromental variables which affect
'ls', neither in man pages nor in info.  Search on 'COLLATE' fails.

			Regards, Dmitri
Comment 3 Steve Bonneville 2001-03-28 12:02:58 EST
Is there a good reason not to do the appropriate equivalent of

  alias ls='LC_COLLATE=C ls --color=tty'

in the /etc/profile.d/colorls.sh and colorls.csh files to head off
the grouching?  Then presumably users that care could turn off the
alias if they want POSIX behavior, and everything using LC_COLLATE
isn't impacted.
Comment 4 Trond Eivind Glomsrxd 2001-03-28 12:12:20 EST
It would break sorting (and filename output) for non-7bit locales, as characters
douldn't be recognized.
Comment 5 Trond Eivind Glomsrxd 2001-03-28 12:20:24 EST
(I need glasses - LC_COLLATE, not LANG or LC_ALL)

No, it would sort wrong for non-ASCII locales, many in which the characters are
not sorted after ASCII code.
Comment 6 Hacksaw 2003-01-30 23:51:35 EST
Please note that one must also set LC_ALL to null, as it overrides LC_COLLATE.

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