On Sat, 15 Mar 2025 20:00:42 +0100, Ingo Schwarze wrote: > Hello, > > Van Dung Ha wrote on Wed, Mar 12, 2025 at 02:25:02PM +0100: > > [...] > > Recently, I was parsing a few IP addresses from the snort logs > > to populate a pf table and encountered something counter-intuitive. > > Here is an example source list. > > > [...] > > 77.224.14.2 > > 77.224.14.21 > > 77.224.14.18 > > 77.224.14.21 > > > > When you sort this list using '| sort -u', you will end up with the > > following, expected list. > [...] > > The weird thing occurs that when you filter the same source list > > using '| sort -hu', you end up with this shorter list > [...] > > Notice that this list is missing 77.224.14.2 and 77.224.14.21! > > Is this by design? > > Others explained why this behaviour is required by POSIX and i just > committed a patch improving our manual page, explaining what the key > used by -u is for the three numerical sort options. > > My first try to get what you want was > > $ sort -nut . -k1 -k2 -k3 -k4 test.in > > but that does not work either, among other things resulting in the > wrong ordering > > 77.224.14.18 > 77.224.14.2 > 77.224.14.21 > > apparently because both OpenBSD sort(1) and GNU coreutils gsort(1) > intepret these lines as two fields of one floating point number each, > with 14.18 < 14.2 < 14.21, and ignore the -k3 and -k4 options. > > I fail to see how our sort(1) manual describes that behaviour, > or how the POSIX specification mandates it, and i do not see an > explanation in the info(1) manual of sort(1) for GNU coreutils > either. So our sort(1) manual can still be improved. > > The easiest way i found to do what you want is > > $ tr . s < test.in | sort -nuts -k1 -k2 -k3 -k4 | tr s . > > nuts in the Karakorum!
sort -V to the rescue! > Yours, > Ingo >
