Re: case insensitivity (rather a wish than a bug)

[David T-G]

Bastian --

...and then Bastian Fuchs said...
% 
% Hello,
% it would be nice, if there is an option to sort alphabetically WITHOUT 
% consideration of upper oder lower case.
% 
% This is the standard output of ls -l:
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 FIRST_EXAMPLE
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 SECOND_EXAMPLE
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 first_example
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 second_example
% 
% It would be nice, if ls -l --sort=caseinsensitivity for example would show:
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 FIRST_EXAMPLE
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 first_example
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 SECOND_EXAMPLE
% -rw-r--r--    1 bastiaf  users           0 Sep  8 01:36 second_example

As a matter of fact, since fileutils 4.1, that is the standard behavior
when your environment is not set to POSIX.  Check out your

  LANG
  LC_CTYPE
  LC_NUMERIC
  LC_TIME
  LC_COLLATE
  LC_MONETARY
  LC_MESSAGES
  LC_PAPER
  LC_NAME
  LC_ADDRESS
  LC_TELEPHONE
  LC_MEASUREMENT
  LC_IDENTIFICATION
  LC_ALL

variables as well as the output of

  locale

(which should spit all of that out) and

  ls --version

to see that you're actually running 4.1 or later and we're not debugging
the wrong problem.  The short form, pruned from how it was explained to
me just a few months ago, looks like:

                                 ... I am not pleased with Redhat and
  Gnome.  Those two groups together have caused a huge problem out of
  this really simple and good feature.  Both of them by default set
  LANG=en_US ...

  When the discussion of localization and internationalization has ever
  come up in the long history of the Internet and standards
  organizations the US software body has always had a black eye since we
  traditionally ignored anyone who did not speak English ...
                ...  Eventually it was agreed upon only after very,
  very, VERY much debate how i18n (internationalization) was to be
  implemented.  ...

  Therefore everyone implements i18n support in their code by calling
  strcoll(3) routines instead of strcmp(3) routines.  The libc takes
  care of everything for you.  For the traditional unix user they see no
  difference at all.  New variables never before seen in a unix
  environment such as LANG and LC_ALL were implemented to switch on this
  new feature but it would be switched on only if the user specifically
  asked for it to be switched on.  Full compatibility is preserved.
  That is the way it should work.  Full compatibility is preserved.

  Then along comes Redhat.  They decide that users really want
  dictionary sorting order and set LANG=en_US ...
                   ...  They don't change the bug reporting address and
  so GNU gets the bug reports. ...  I just wish the disgruntlement
  was directed toward RH and not to GNU ...

  Of course you are hosed if a vendor sets that variable for you.  Then
  you do have to know to clean it out of your environment first.  Thank
  you for knowing what is best for me.  Phooey!

Anyway, in my case I had

  LANG=

but

  LC_CTYPE=en_US.ISO8859-1

and so I was using case-insensitive dictionary sort order; the answer was
to either set everything to POSIX or to nothing or to be sure to set
LC_CTYPE and LC_COLLATE to POSIX.  You're probably in the same boat.


% 
% - Bastian


HTH & HAND

:-D
-- 
David T-G                      * It's easier to fight for one's principles
(play) address@hidden * than to live up to them. -- fortune cookie
(work) address@hidden
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

pgpIsula0cU3m.pgp
Description: PGP signature