Red Hat Bugzilla – Bug 33141
ls alphabethical sort does not respect capitalization and starting .
Last modified: 2007-04-18 12:32:22 EDT
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.
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 ;) )
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
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.
It would break sorting (and filename output) for non-7bit locales, as characters douldn't be recognized.
(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.
Please note that one must also set LC_ALL to null, as it overrides LC_COLLATE.