Bug 33141 - ls alphabethical sort does not respect capitalization and starting .
Summary: ls alphabethical sort does not respect capitalization and starting .
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: fileutils
Version: 7.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Aaron Brown
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-25 23:04 UTC by pogosyan
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-03-25 23:04:14 UTC
Embargoed:


Attachments (Terms of Use)

Description pogosyan 2001-03-25 23:04:11 UTC
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
2.
3.
	

Actual Results:  > /bin/ls -1
addressbook_vcard.py
addressbook_vcard.pyc
AUTHORS
ChangeLog
config.py
config.pyc
COPYING


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 12:30:52 UTC
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 16:58:23 UTC
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
order).
............end-of-quote

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 17:02:58 UTC
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 17:12:20 UTC
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 17:20:24 UTC
(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-31 04:51:35 UTC
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.