[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ls sort order bug
From: |
Matthew Vanecek |
Subject: |
Re: ls sort order bug |
Date: |
23 Nov 2002 09:28:10 -0600 |
David,
Thanks for you reply. I did a little poking around, based on your
advice about LANG. (BTW, I do have v4.1). I set my LANG to the POSIX
English setting (C) instead of American English (en_US), and now ls
works like I know and love. I appreciate your reply and apologize for
considering it a bug in ls. I may have to submit a patch to (someone)
to correct the behavior when LANG=en_US. That's just very frustrating
(where's README!! why is it with rpm!!). Until that's fixed, I think
I'll try POSIX English.
Thanks.
On Fri, 2002-11-15 at 05:04, David T-G wrote:
> 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.
>
> So who the hell decided that en_US would want to sort without case
> sensitivity?? Damned Microsofties! ;-)
>
>
--
Matthew Vanecek <address@hidden>
signature.asc
Description: This is a digitally signed message part