bug#7407: about the order result of the sort command

[Eric Blake]

On 11/15/2010 01:17 AM, 黄东喜 wrote:
> address@hidden ~]$ 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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature