bug#18273: sort seems to misbehave if both -u and -n or -k are used

[Lennart Sorensen]

Here is the case that has me thinking there is a bug (it sure doesn't
make sense as valid behaviour).

input:

Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u7
Version: 1.0.1e-2+deb7u11

OK output using 'sort':

Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u7

OK output using 'sort -u':

Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u7

OK output using 'sort -n':

Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u7

(I may have hoped that one would sort by the last number given everything
else is equal, but I did not expect it to actually do so).

OK output using 'sort -k 3':

Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u11
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u12
Version: 1.0.1e-2+deb7u7

Weird output using 'sort -n -u':

Version: 1.0.1e-2+deb7u12

Weird output using 'sort -k 3 -u':

Version: 1.0.1e-2+deb7u12

So is this actually the expected behaviour?  I would have thought from
the documentation that -u would return unique lines of output, not just
one line based on whatever sort key it happened to look at.

-- 
Len Sorensen