[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] add sort option for IP addresses

From: Norbert Kiesel
Subject: Re: [patch] add sort option for IP addresses
Date: Mon, 27 Nov 2006 20:01:11 +0100

On Mon, 2006-11-27 at 10:12 -0800, Paul Eggert wrote:
> Norbert Kiesel wrote:
> > I needed to sort some text by IP addresses, and there does not seem to
> > be a good way to do it. They only trick I found was "-n -t. -k1,1 -k2,2
> > -k3,3 -k4.4" or so, but that is kind of ugly.
> The coreutils manual suggests:
> sort -t '.' -k 1,1n -k 2,2n -k 3,3n -k 4,4n
Not in my case where I have a random number of '.' in the text before
the IP.  I could of course reorder the columns so that the IP is the
first column, then sort, then reorder again, but this really gets ugly

> It is a bit ugly, but it's fine for scripts.
> Pádraig Brady <address@hidden> writes:
> > For IPV4 this is too specific IMHO.
> I tend to agree.  "sort" should have a way to plug in arbitrary
> comparison functions.  For example, it might add an option to open a
> pipe to another process, feed it two lines, and expect a response "<",
> "=", ">".  Or perhaps there's a better way; but the point is that
> these algorithms should not all have to be hardwired into "sort".
> > You may have a point though for comparing IPV6 addresses.
> > I can't figure out a general method at least.
The inet_aton can also deal with IPv6 addresses, so I could either try
to auto-detect the 4/6 (e.g. contains a ':' => 6, else 6), or add
another option to let the user pick.

> Yes, it'd be tricky to reduce it to a -k recipe even if we added
> support for comparing hexadecimal numbers to 'sort' (a far more likely
> candidate for inclusion), because of mixed addresses and the ::
> notation.  E.g., comparing 0:0:0:0:0:FFFF: to FF01::101
> would be quite tricky with just -k and hex.
What's wrong with inet_pton(AF_INET6, ...), then ntohl the 4 ints and
simply compare them left to right? Will give a well defined order, and
for most cases also what the user expects (or at least I would expect).

> Better would be support for arbitrary comparison plugins.

Are there plans for this? Or even a design?  My code is of course very
limited, but then also not really intrusive and it works.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]