bug-fileutils
[Top][All Lists]
Advanced

[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>

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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