[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: 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:

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

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]