GNU bug report logs - #9808
sort behavior

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9808 in the body.
You can then email your comments to 9808 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: mohamad hadi kianersi <mohamad.hadi.kianersi <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: bug report
Date: Thu, 20 Oct 2011 14:32:12 +0330

[Message part 1 (text/plain, inline)]

Hi
when use sort with option k(key)r(revers) after these options when use
n(numeric)  dont sort with numeric option


-- 

Mohamad Hadi Kianersi

[Message part 2 (text/html, inline)]

Message #8 received at 9808 <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

Message #19 received at 9808-done <at> debbugs.gnu.org (full text, mbox):

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

tag 9808 = notabug
thanks

Re-adding the list, so that others may benefit from the solution or 
chime in with suggestions.

On 10/20/2011 07:36 AM, mohamad hadi kianersi wrote:
> yes,but view these
>
> 1.
> [hadi <at> hadi ~]$  printf '10 a\n1 b\n2 c\n' | sort -k1,1 -r -n
> 10 a
> 2 c
> 1 b
>
> but
> [hadi <at> hadi ~]$  printf '10 a\n1 b\n2 c\n' | sort -k1,1r -n
> 2 c
> 10 a
> 1 b
> cant sorted with numeric

Did you try 'sort --debug' like I suggested?

$ printf '10 a\n1 b\n2 c\n' | LC_ALL=C sort -k1,1r -n --debug
sort: using simple byte comparison
sort: option `-n' is ignored
2 c
_
___
10 a
__
____
1 b
_
___

Notice - sort is _correctly_ ignoring -n, and --debug even tells you so, 
per the rules given by POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

"The following options shall override the default ordering rules. When 
ordering options appear independent of any key field specifications, the 
requested field ordering rules shall be applied globally to all sort 
keys. When attached to a specific key (see -k), the specified ordering 
options shall override all global ordering options for that key." [d, f, 
i, n, r]

That is, the moment you use -k with r attached, then the global -n no 
longer applies to that -k; to get both r and n behavior on a single key, 
you have to attach both options to that -k:

$ printf '10 a\n1 b\n2 c\n' | LC_ALL=C sort -k1,1rn --debug
sort: using simple byte comparison
10 a
__
____
2 c
_
___
1 b
_
___

As such, I'm closing this bug report, now that we know the problem was a 
usage error and not a bug in sort.

-- 
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.