On 11/15/2010 01:17 AM, 黄东喜 wrote: > [huangdon...@localhost ~]$ echo "1001661 277 > >> 1001662 888 > >> 100166 73" | sort > > 1001661 277 > > 1001662 888 > > 100166 73
Thanks for the report. However, this is most likely not a bug in sort, but in your expectations. This is a FAQ, and is probably due to your locale: http://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021 Using the new 'sort --debug' feature of coreutils 8.7 shows: $ echo "1001661 277 1001662 888 100166 73" | sort --debug sort: using `en_US.UTF-8' sorting rules 1001661 277 ___________ 1001662 888 ___________ 100166 73 _________ $ echo "1001661 277 1001662 888 100166 73" | LC_ALL=C sort --debug sort: using simple byte comparison 100166 73 _________ 1001661 277 ___________ 1001662 888 ___________ Remember, many non-C locales ignore whitespace in collation rules. > > It is different from the sort order of the “join” command. Reread 'join --help': > Important: FILE1 and FILE2 must be sorted on the join fields. E.g., > use ` sort -k 1b,1 ' if `join' has no options, or use ` join -t '' ' if > `sort' has no options. Note, comparisons honor the rules specified by > `LC_COLLATE'. If the input is not sorted and some lines cannot be > joined, a warning message will be given. If you correctly sorted with -k 1b,1 (or if you correctly used join -t ''), then you will get consistent results for your current locale (whether or not you also choose to change things to require LC_ALL=C). -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature