bug-coreutils
[Top][All Lists]
Advanced

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

bug#14226: Sort -c takes in account fields that were outside sorting sco


From: Camion SPAM
Subject: bug#14226: Sort -c takes in account fields that were outside sorting scope
Date: Sat, 20 Apr 2013 01:56:13 +0100 (BST)

Well, I'm satisfied with your suggestion of adding -s. 
I would just add that this might be something that should be added to the man 
page.


________________________________
 De : Eric Blake <address@hidden>
À : Camion SPAM <address@hidden> 
Cc : address@hidden 
Envoyé le : Jeudi 18 avril 2013 21h53
Objet : Re: bug#14226: Sort -c takes in account fields that were outside 
sorting scope
 

tag 14226 notabug
thanks

On 04/18/2013 09:04 AM, Camion SPAM wrote:
> The following commands report an error on equals lines because field outside 
> sorting scope were not sorted

How refreshing to get a non-FAQ report on sort - you made me actually do
some research!  The fact that you used LANG=C to pin the locale is also
nice (most people aren't aware that most reported non-bugs in sort are
due to locale issues).  However, I still think sort is doing the right
thing.

> 
> $ cat <<'.' |
>> AAA AAA
>> BBB BBB
>> ZZZ CCC
>> DDD DDD
>> BBC EEE
>> BBD EEE
>> BBC EEE
>> BBE EEE
>> CCC FFF
>> DDD GGG
>> EEE HHH
>> .
>> LANG=C sort -k 2,2 -c
> sort: -:7: disorder: BBC EEE

POSIX says:
"Except when the -u option is specified, lines that otherwise compare
equal shall be ordered as if none of the options -d, -f, -i, -n, or -k
were present (but with -r still in effect, if it was specified) and with
all bytes in the lines significant to the comparison."
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html

In your example, you did not use -u, and the key you specified was
duplicated between two rows, so POSIX requires sort to break the tie by
comparing the entire line, and the entire line is indeed different.

For comparison purposes, I checked out /usr/bin/sort on Solaris 10; it
has the same behavior of declaring your input unsorted.
/usr/xpg4/bin/sort on the same machine is not POSIX compliant, in that
it lacks -C, and treats -c like the POSIX -C; but it also had non-zero
exit status on your sample.

If you don't like the POSIX behavior of a mandated entire line as a sort
key of final resort, then you should use the GNU extension of -s, I
tested that 'LC_ALL=C sort -k2,2 -c -s' has no problems with your
example.  To see the difference of using or not using the entire line as
the final sort key, replace -c by --debug, both with and without -s (you
can't use -c and --debug at the same time, unfortunately).  However,
remember that not all sort implementations have -s, so there is no
standard way to get the behavior you are after.

I'm closing this as not a bug, although you may continue to add comments
or questions to this topic.

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


reply via email to

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