[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#9808: sort behavior [was: bug#9808: bug report]

From: Eric Blake
Subject: bug#9808: sort behavior [was: bug#9808: bug report]
Date: Thu, 20 Oct 2011 07:30:27 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.15

retitle 9808 sort behavior
tag 9808 moreinfo

On 10/20/2011 05:02 AM, mohamad hadi kianersi wrote:
when use sort with option k(key)r(revers) after these options when use
n(numeric)  dont sort with numeric option

Thanks for the report. However, you did not give us any details with which to reproduce your claim of the behavior you tried, the output you got, and the output you expected. Would you mind pasting an actual 3 or 4 line file, and the actual sort command line you used, to demonstrate the question you are asking? Most likely, it will turn out that the problem is not a bug in sort, but that you are using it incorrectly. For an example, here's something I tried based on your explanation, but I have no idea if I'm reproducing the behavior you are questioning:

$ printf '10 a\n1 b\n2 c\n' | sort -n -r -k1,1
10 a
2 c
1 b

Also, have you tried using 'sort --debug'? Newer coreutils provides this as a great way to understand a lot of situations why sort is behaving correctly, but differently than your expectations.

Your bug report was low quality. I'd suggest reading this page, and take to heart the ideas such as a better subject line and doing more to help the developers reproduce your issue:

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

reply via email to

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