GNU bug report logs - #22084
Potential Bug in sort -r

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 22084 in the body.
You can then email your comments to 22084 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: Adrià Rovira <adria.rovira <at> upc.edu>
To: bug-coreutils <at> gnu.org
Cc: Deimos Ibanez Segura <deimos.ibanez <at> upc.edu>
Subject: Potential Bug in sort -r
Date: Thu, 03 Dec 2015 13:30:06 +0100

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

Dear GNU,

I am using the sort command in  (GNU coreutils) version 8.13

I noticed the reverse option is not correctly applied if it has to sort by
more than one column.

This behaviour is corrected by forcing again the type of sort.

This happens with -n and -g.

Example:

echo -e "930 7.83\n930 77.52\n930 54.09" | sort -n -k1 -k2r
930 7.83
930 77.52
930 54.09
echo -e "930 7.83\n930 77.52\n930 54.09" | sort -n -k1 -k2rn
930 77.52
930 54.09
930 7.83

Kind Regards,

Adrià and Deimos
 --------------------------------------------------------
o o o | Adrià Rovira Garcia
o o o | Research group of Astronomy and GEomatics (gAGE)
o o o | Universitat Politècnica de Catalunya (UPC)
--------------------------------------------------------

gAGE / UPC
Departament de Matemàtiques
C/. Jordi Girona 1-3
Campus Nord UPC
Building C3, Office 211
08034 Barcelona, Spain
Tel:+34 93 401 25 31
Fax:+34 93 401 59 81
http://www.gage.upc.edu

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

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Adrià Rovira <adria.rovira <at> upc.edu>, 22084 <at> debbugs.gnu.org
Cc: Deimos Ibanez Segura <deimos.ibanez <at> upc.edu>
Subject: Re: bug#22084: Potential Bug in sort -r
Date: Thu, 3 Dec 2015 12:18:04 -0500

tag 22084 notabug
close 22084
stop

Hello Adrià and Deimos,


On 12/03/2015 07:30 AM, Adrià Rovira wrote:
> I noticed the reverse option is not correctly applied if it has to sort by more than one column.

This is not a bug, but simply a usage issue.
The "sort --help" page states:
" ... OPTS is one or more single-letter ordering options [bdfgiMhnRrV],
which override global ordering options for that key. "

That is,
1. If you use global sorting option (-n), and a key option WITHOUT
   ordering option (e.g. '-k1,1') - the global sorting option is in effect.

2. If you use *any* sorting option in the key specification
 (e.g. '-k1,1r'), it overrides the global sorting option,
 thus the order in effect is just 'reverse' (implying: alphabetical order).

These examples should demonstrate it:

    # Input data
    $ printf "1\n07\n2\n"
    1
    07
    2
    
    # Alphabetical (ascii) sort,
    # character "0" comes before "1"
    $ printf "1\n07\n2\n" | sort
    07
    1
    2
    
    # Numerical sort, value 7 comes after 2
    $ printf "1\n07\n2\n" | sort -n
    1
    2
    07
    
    # Global option (-n), key without ordering option:
    # numeric sort in effect
    $ printf "1\n07\n2\n" | sort -n -k1,1
    1
    2
    07
    
    # Global option (-n), key with any ordering option
    # (in this case 'b' = ignore leading blanks)
    # global numeric ordering is ignore
    $ printf "1\n07\n2\n" | sort -n -k1b,1
    07
    1
    2
    
    # Adding the numeric ordering to the key -
    # takes effect
    $ printf "1\n07\n2\n" | sort -n -k1bn,1
    1
    2
    07


regards,
 - Assaf

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

From: Eric Blake <eblake <at> redhat.com>
To: Adrià Rovira <adria.rovira <at> upc.edu>,
 22084-done <at> debbugs.gnu.org
Cc: Deimos Ibanez Segura <deimos.ibanez <at> upc.edu>,
 GNU bug control <control <at> debbugs.gnu.org>
Subject: Re: bug#22084: Potential Bug in sort -r
Date: Thu, 3 Dec 2015 10:19:36 -0700

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

tag 22084 notabug
thanks

On 12/03/2015 05:30 AM, Adrià Rovira wrote:
> Dear GNU,
> 
> I am using the sort command in  (GNU coreutils) version 8.13
> 
> I noticed the reverse option is not correctly applied if it has to sort by
> more than one column.
> 
> This behaviour is corrected by forcing again the type of sort.
> 
> This happens with -n and -g.
> 
> Example:
> 
> echo -e "930 7.83\n930 77.52\n930 54.09" | sort -n -k1 -k2r

First, a couple of notes:

'echo -e' is not portable; you should consider using printf(1) instead.

Then, you are not specifying the keys you thought.  Let's look at this
with sort's --debug option:

$ printf '930 7.83\n930 77.52\n930 54.09\n' | sort -n -k1 -k2r --debug
sort: using ‘en_US.UTF-8’ sorting rules
sort: key 1 is numeric and spans multiple fields
sort: leading blanks are significant in key 2; consider also specifying 'b'
930 7.83
___
   _____
________
930 77.52
___
   ______
_________
930 54.09
___
   ______
_________

You probably want to use the -k1,1 notation and an explicit -b to ensure
that your field usage is sane:

$ printf '930 7.83\n930 77.52\n930 54.09\n' | sort -n -k1,1 -k2b,2r --debug
sort: using ‘en_US.UTF-8’ sorting rules
930 7.83
___
    ____
________
930 77.52
___
    _____
_________
930 54.09
___
    _____
_________

Now, on to your actual report.  Here is what 'info sort' says:

   A position in a sort field specified with ‘-k’ may have any of the
option letters ‘MbdfghinRrV’ appended to it, in which case no global
ordering options are inherited by that particular field.  The ‘-b’
option may be independently attached to either or both of the start and
end positions of a field specification, and if it is inherited from the
global options it will be attached to both.  If input lines can contain
leading or adjacent blanks and ‘-t’ is not used, then ‘-k’ is typically
combined with ‘-b’ or an option that implicitly ignores leading blanks
(‘Mghn’) as otherwise the varying numbers of leading blanks in fields
can cause confusing results.

Or, referring to POSIX:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

    The keydef argument is a restricted sort key field definition. The
format of this definition is:

    field_start[type][,field_end[type]]

    where field_start and field_end define a key field restricted to a
portion of the line (see the EXTENDED DESCRIPTION section), and type is
a modifier from the list of characters 'b', 'd', 'f', 'i', 'n', 'r'. The
'b' modifier shall behave like the -b option, but shall apply only to
the field_start or field_end to which it is attached. The other
modifiers shall behave like the corresponding options, but shall apply
only to the key field to which they are attached; they shall have this
effect if specified with field_start, field_end, or both. If any
modifier is attached to a field_start or to a field_end, no option shall
apply to either.


So the moment you add 'r' to a particular -k, that key is no longer
benefiting from the global -n option, and you are correct that you then
have to re-specify 'n' on a per-'-k' basis, as you did here:

> echo -e "930 7.83\n930 77.52\n930 54.09" | sort -n -k1 -k2rn
> 930 77.52
> 930 54.09
> 930 7.83

Since this is the documented behavior, and matches the POSIX
requirement, there is no bug.  I'm thus closing out this report;
however, feel free to add further comments to the thread.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

[signature.asc (application/pgp-signature, attachment)]

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

From: Adria Rovira <adria.rovira <at> upc.edu>
To: Assaf Gordon <assafgordon <at> gmail.com>, 22084 <at> debbugs.gnu.org
Cc: Deimos Ibanez Segura <deimos.ibanez <at> upc.edu>
Subject: Re: bug#22084: Potential Bug in sort -r
Date: Thu, 3 Dec 2015 18:28:43 +0100

Dear Assaf,

Thank You very much!!

We didn't read carefully enough the manual.

Best Regards,

Adrià


On 12/03/2015 06:18 PM, Assaf Gordon wrote:
> tag 22084 notabug
> close 22084
> stop
>
> Hello Adrià and Deimos,
>
>
> On 12/03/2015 07:30 AM, Adrià Rovira wrote:
>> I noticed the reverse option is not correctly applied if it has to 
>> sort by more than one column.
>
> This is not a bug, but simply a usage issue.
> The "sort --help" page states:
> " ... OPTS is one or more single-letter ordering options [bdfgiMhnRrV],
> which override global ordering options for that key. "
>
> That is,
> 1. If you use global sorting option (-n), and a key option WITHOUT
>    ordering option (e.g. '-k1,1') - the global sorting option is in 
> effect.
>
> 2. If you use *any* sorting option in the key specification
>  (e.g. '-k1,1r'), it overrides the global sorting option,
>  thus the order in effect is just 'reverse' (implying: alphabetical 
> order).
>
> These examples should demonstrate it:
>
>     # Input data
>     $ printf "1\n07\n2\n"
>     1
>     07
>     2
>         # Alphabetical (ascii) sort,
>     # character "0" comes before "1"
>     $ printf "1\n07\n2\n" | sort
>     07
>     1
>     2
>         # Numerical sort, value 7 comes after 2
>     $ printf "1\n07\n2\n" | sort -n
>     1
>     2
>     07
>         # Global option (-n), key without ordering option:
>     # numeric sort in effect
>     $ printf "1\n07\n2\n" | sort -n -k1,1
>     1
>     2
>     07
>         # Global option (-n), key with any ordering option
>     # (in this case 'b' = ignore leading blanks)
>     # global numeric ordering is ignore
>     $ printf "1\n07\n2\n" | sort -n -k1b,1
>     07
>     1
>     2
>         # Adding the numeric ordering to the key -
>     # takes effect
>     $ printf "1\n07\n2\n" | sort -n -k1bn,1
>     1
>     2
>     07
>
>
> regards,
>  - Assaf
>
>


-- 
--------------------------------------------------------
o o o | Adrià Rovira Garcia
o o o | Research group of Astronomy and GEomatics (gAGE)
o o o | Universitat Politècnica de Catalunya (UPC)
--------------------------------------------------------

gAGE / UPC
Departament de Matemàtiques
C/. Jordi Girona 1-3
Campus Nord UPC
Building C3, Office 211
08034 Barcelona, Spain
Tel:+34 93 401 25 31
Fax:+34 93 401 59 81
http://www.gage.upc.edu

Previous Next

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