Description:

This is a rather odd issue, and I'm not sure the patch is entirely to blame, however I was unable to isolate the issue beyond that.

Human-readable numeric sort works fine in my own binary compiled from upstream sources, but sorts incorrectly once I patch it with an appropriate excerpt from coreutils-i18n.patch used by the coreutils PKGBUILD, and likewise sort directly from the current package fails as well.

The reason I'm unsure it's entirely due to the patch is because I have a VM that's five months out of date, running kernel 2.6.32.9-1, glibc 2.11.1-1. I've tried coreutils 8.4-1, 8.5-1 and several intermediate revisions on it, and sort works as expected, yet sha1sum-identical sort binaries don't work properly on up-to-date systems.

Even downgrading everything sort links against (kernel26*, glibc, all dependencies thereof) as well as all coreutils dependencies to versions from five months ago, I cannot get my otherwise up-to-date system to duplicate the (proper) results from the five-month-old VM, so while the patch is the most obvious cause, it seems it's only triggering a symptom.

Steps to reproduce:

Feed something like the following to 'sort -k3h':
3 A 1M
5 G 2K
4 C 4G
8 F 8K
1 J 16M

The intended output should obviously be sorting the third column by human-readable sizes, but the actual output is sorted by the first column. sort -k3 sorts by the third column and awk '{print $3}' | sort -h sorts properly. It's only when they're combined that things fall apart.