Re: ls sort order bug

Matthew --

...and then Matthew Vanecek said...
% 
% The ls man page advertises that ls will "Sort entries alphabetically if

What version of ls on what operating system, please?


% none of -cftuSUX" are specified.  -a is supposed to show the .
% directories/files.

Right.


% 
% The bug is that the . files/directories are intermixed with the other
% files/directories, and that lower case and upper case files/directories
% are intermixed.  To sort alphabetically, the . files must come first,
% followed by Upper case files, followed by lower case files.
% I cannot find a combination of options that outputs the expected
% listing.

It sounds to me like you have a 4.1 or later version of fileutils (run

  ls --version

to check) and do not have the proper localization environment variables
set for the results you want.  I assure you that ls can be directed to
either fold or honor case, and I've never seen . and .. anywhere except
at the top of the listing.

To make a painfully long story short, here is some paraphrased background
purely from memory (and thus subject to inaccuracy on many counts, but I
hope at least a start):

- When *NIX utilities were first written, program behavior, user
  interface, and error messages were all coded directly within the
  program.  Easy and simple, but no support for other languages.

- When the POSIX standard was developed, support for internationalization
  was designed in from the start, allowing hooks to language and locale
  specs so that a program could talk to the user the way the user wants
  to hear it.  As of 4.1, the GNU FileUtils are fully POSIX compliant.

- Unfortunately, certain operating system vendors (I will not mention
  specifically one known for its crimson fedora, since I do not use it,
  but it is my understanding that they are a very common source of this
  problem) assume that their users will want a certain behavior -- say,
  to fold case as in MS Windows Explorer -- and set the LANG* and LC_*
  variables accordingly -- WITHOUT TELLING THE USER who is setting up the
  system.

- The GNU FileUtils team then gets the "bug report" when, in fact, all
  they've done is write good code and move to a more universal standard.

As I said, I've never seen . and .. anywhere but up front; if you can
document aberrant behavior, I'm sure we'd be interested in seeing your
results.  If that's not the case, then you'll need to first check 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

environment variables to make sure that at least LANG, LC_CTYPE, and
LC_COLLATE are not set to en_US.  A quote from when *I* went through the
investation of this back in June 2002:

  So although I didn't have LANG or LC_ALL set I did have LC_CTYPE and/or
  LC_COLLATE and those screwed me until I either set LANG and/or LC_ALL to
  POSIX or unset LC_CTYPE and/or LC_COLLATE.  Ouch.

  So who the hell decided that en_US would want to sort without case
  sensitivity??  Damned Microsofties! ;-)


% 
% -- 
% Matthew Vanecek <[email protected]>


HTH & HAND

:-D
-- 
David T-G                      * There is too much animal courage in 
(play) [email protected] * society and not sufficient moral courage.
(work) [email protected]  -- Mary Baker Eddy, "Science and Health"
http://www.justpickone.org/davidtg/    Shpx gur Pbzzhavpngvbaf Qrprapl Npg!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (FreeBSD)

iD8DBQE91NS9Gb7uCXufRwARApB9AKDB75twE1xJJQzORAKwc6iOfL68igCdHtxz
DRi01AsOLq1rR8ITD74k0ac=
=AlpJ
-----END PGP SIGNATURE-----