[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#8214: red hat lynx 'sort' bug?
From: |
Eric Blake |
Subject: |
bug#8214: red hat lynx 'sort' bug? |
Date: |
Wed, 09 Mar 2011 14:12:51 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.7 |
On 03/09/2011 01:47 PM, Niergarth, Jeffrey wrote:
> The 'sort' utility (no options) doesn't behave as expected:
Thanks for the report. However, I fail to see that this is a bug.
>
> Here are the pertinent results:
>
> /fpga/OAF/HD/rtl/vhdl_wrapper/clock_monitor_synthesis.v
> /fpga/OAF/HD/rtl/vhdl_wrapper/clockmonitor_synthesis.v
> /fpga/OAF/HD/rtl/vhdl_wrapper/clock_monitor_synthesis.v IN
> /fpga/OAF/HD/rtl/vhdl_wrapper/clockmonitor_synthesis.v IN
This looks reasonable if you are using a locale that discards
punctuation from collation sorting (such as many implementations of
en_US.UTF-8). This is a FAQ:
http://www.gnu.org/software/coreutils/faq/#Sort-does-not-sort-in-normal-order_0021
Try 'LC_ALL=C sort' on the same data, to force all bytes to behave in
ASCII ordering. I'm marking this bug as closed for now, but if you can
provide compelling evidence that there really is a bug in sort after you
sort out your locale, then we can re-open it. You may also want to try
the 'sort --debug' option in the latest coreutils 8.10 to help diagnose
what sort is really doing, and why it is correct (even if it is not what
you were wanting, because you didn't use the right command line options
and locale environment variables).
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature