Randall Hopper <[EMAIL PROTECTED]> [2002-08-31 10:32:29 -0400]:
> The GNU sort command (textutils-2.1) by default does this:
>
> --ignore-case
> --dictionary-order
Thanks for the report. But you are mistaken. That is not the default
behavior for sort. Sort only behaves that way if specifically told to
behave that way.
> I want to disable this so it behaves like other UNIX sorts. The man page
> does not describe how to do this, so I assume it isn't supported.
I understand your complaint. And patches to the documentation are
always welcomed.
The man pages are automatically generated by the help2man program
which takes the 'sort --help' output and generates the man page. In
this they make good reference pages. The full documentation is
supplied as info pages which make better user guides. Therefore the
man page points to the info documentation for the full reference.
The full documentation for sort is maintained as a Texinfo
manual. If the info and sort programs are properly
installed at your site, the command
info sort
should give you access to the complete manual.
The in the info page it says this. Which is probably hard to pick out
from among the other information there. It just does not jump off of
the page but there it is none the less.
Unless otherwise specified, all comparisons use the character
collating sequence specified by the `LC_COLLATE' locale.
Okay, so it is a little twisty to get here. You had to read the info
page and if you don't know about locales then you will have to read
about them to understand this statement. The conformance to standards
and following locales started with 2.0 and before that GNU sort did
not respect locales. The documentation in this area is still
improving. But if LC_COLLATE is telling sort to sort differently then
then it _must_ comply.
Actually sort just passes the problem off to the C library. The C
library routine strcoll() does all of the work. It is useful to read
the man page for strcoll() which also describes sort. This is the
basis of all sorting such as that done by 'ls' as well.
man strcoll
> For example, when sorting directory listings, you end up getting less
> useful orderings like this, which I don't want. I want the dot files
> clustered together (sorting by ASCII value, not skipping any characters):
>
> ./.gnupg/random_seed
> ./HOUSE/BUYSELL/mortgage
> ./HOUSE/TODO/20020824
> ./HUMOR
> ./.ICEauthority
What does your 'locale' output say that you have specified for sort
order?
Use the 'locale' command to print out what sorting order you have
configured in your environment. If it does not say "C" or "POSIX"
then you have configured a non-standard sorting order. In which case
it is not a bug in sort but behavior which is specifically required.
Most generally reported is that your vendor set LANG for you to en_US
because they think you like it that way. If you disagree then you
might consider filing a bug report with them.
Here is a standard reply.
Bob
Please check out the FAQ section on sort.
http://www.gnu.org/software/fileutils/doc/faq/#Sort%20does%20not%20sorting%20i
+n%20normal%20order!
This is due to the fact that you or your vendor have set environment
variables that direct the program to use locale specific sorting
tables which do not sort as you expect. You or your vendor have
probably set environment variables like LANG, LC_ALL, or LANG to
en_US. Use the 'locale' program to display your current settings.
Unset them, and then set LC_ALL to POSIX.
# If you use bash or some other Bourne-based shell,
export LC_ALL=POSIX
# If you use a C-shell,
setenv LC_ALL POSIX
and it will then work the way you expect because it will use a
different set of tables.
See the standards documentation for more information on the locale
variables with regards to sort.
http://www.unix-systems.org/single_unix_specification_v2/xcu/sort.html
_______________________________________________
Bug-textutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-textutils
