[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
sort bug with -n ?
From: |
Bruno Haible |
Subject: |
sort bug with -n ? |
Date: |
Tue, 2 Jan 2007 22:05:39 +0100 |
User-agent: |
KMail/1.9.1 |
Hi,
When 'sort' is fed input without spaces, one would expect that
sort -t . [OTHER-OPTIONS]
produces the same sort order as
tr '.' ' ' | sort [OTHER-OPTIONS]
Right? That's not the case with GNU sort 6.7:
$ printf '8.0.2\n8.1.0\n8.0.3\n10.1.0\n8.0.11\n11.0.0\n' > input
$ cat input | sort -t . -k1 -k2 -k3 -k4 -k5 -n -r
11.0.0
10.1.0
8.1.0
8.0.3
8.0.2
8.0.11
$ cat input | tr '.' ' ' | sort -k1 -k2 -k3 -k4 -k5 -n -r
11 0 0
10 1 0
8 1 0
8 0 11
8 0 3
8 0 2
The latter is the expected sorting order; I would have expected the same
sorting order also from the first command. Interestingly its result is also
locale dependent:
$ cat input | LC_ALL=C sort -t . -k1 -k2 -k3 -k4 -k5 -n -r
11.0.0
10.1.0
8.1.0
8.0.3
8.0.2
8.0.11
$ cat input | LC_ALL=de_DE.UTF-8 sort -t . -k1 -k2 -k3 -k4 -k5 -n -r
8.0.11
11.0.0
10.1.0
8.1.0
8.0.3
8.0.2
POSIX says that "Comparisons shall be based on one or more sort keys extracted
from each line of input", and regardless which locale is used, the sort keys
extracted are:
11 0 0
...
8 0 11
It appears that GNU sort reinserts field separators here, otherwise the
result wouldn't be locale dependent?
Bruno
- sort bug with -n ?,
Bruno Haible <=