[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ls sort order bug

From: David T-G
Subject: Re: ls sort order bug
Date: Fri, 15 Nov 2002 06:04:29 -0500
User-agent: Mutt/1.4i

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.


% 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

- 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


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 <address@hidden>


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

Attachment: pgpJ1o4_RrHme.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]