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
signature.asc
Description: OpenPGP digital signature
--- End Message ---