Red Hat Bugzilla – Bug 25953
ls listing is no longer the Unix standard 'capitals first'
Last modified: 2007-04-18 12:31:08 EDT
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
Steps to Reproduce:
1.type 'ls -1' (in this example)
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. :)
POSIX requires that sorting respects locales.
If you don't like it, export LC_COLLATE=C.
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).
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 ...
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.
[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.)
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?
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!
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.