GNU bug report logs - #9808
sort behavior

Previous Next

Full log

Message #12 received at control <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: mohamad hadi kianersi <mohamad.hadi.kianersi <at> gmail.com>
Cc: 9808 <at> debbugs.gnu.org
Subject: sort behavior [was: bug#9808: bug report]
Date: Thu, 20 Oct 2011 07:30:27 -0600

retitle 9808 sort behavior
tag 9808 moreinfo
thanks

On 10/20/2011 05:02 AM, mohamad hadi kianersi wrote:
> Hi
> 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:
http://www.catb.org/~esr/faqs/smart-questions.html

-- 
Eric Blake   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.