Bug 33141

Summary:	ls alphabethical sort does not respect capitalization and starting .
Product:	[Retired] Red Hat Linux	Reporter:	pogosyan
Component:	fileutils	Assignee:	Bernhard Rosenkraenzer <bero>
Status:	CLOSED NOTABUG	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.0
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-03-25 23:04:14 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.