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!
msg01982/pgp00000.pgp
Description: PGP signature
