Bug#1024660: ITP: ranges -- Command line program to extract ranges from various types of lists, e.g. integer numbers, dates, IP and MAC addresses.

[Sandro-Alessio Gierens <sandro@gierens.de>]

Package: wnpp
Severity: wishlist
Owner: Sandro-Alessio Gierens <sandro@gierens.de>

* Package name    : ranges
  Version         : 1.0.0
  Upstream Author : Sandro-Alessio Gierens <sandro@gierens.de>
* URL             : https://github.com/gierens/ranges
* License         : GPLv3
  Programming Lang: C
  Description     : Command line program to extract ranges from various types of lists, e.g. integer numbers, dates, IP and MAC addresses.

ranges is a command line program written in C that extracts ranges from
various types of lists. By default it parses signed decimal integer
lists, but given the right argument it can work with unsigned
hexadecimal, octal and binary numbers, dates, IPv4, IPv6 and MAC
addresses. The list input is given over the standard input, so by pipe,
and is assumed to be sorted, but can have duplicates.

Relevance

I work in a data center and recently had the problem that I needed to
find out which IP addresses of a subnet were not yet assigned in
a /etc/hosts file. Because there were already too many addresses to
get a good overview, I began to wonder if there was any command line
tool that would allow me to compile the list of IPs into a list of
IP ranges, so the gaps and their size would be obvious. Unfortunately
I only found stack overflow discussions suggesting writing a script,
and this is what I did to back then too. While this usually doesn't
take more than a couple of minutes, ranges has too advantages:
It already implements a bunch of different list types including
nasty things like dates for example, and therefore would spare
people from replementing such scripts over and over again. Aside
from that it is written in C and therefore fast. According to my
tests it is, depending on the machine, 20 to 40 times faster than
a comparable Python3 script. It can crunch 130 MB of IPv4 addresses
in a second.

Eventhough I just published the initial release I've been working on
this for a couple of weeks now and extensively checked that it is
stable and secure. My test suite consists of 185 tests that verify
the correct functionality of each mode and argument. Each test is
first run without and then with valgrind memcheck, so there should
not be any leaks or other memory errors.

Maintainance

As the upstream author of the software I would also maintain the
package. This would be my first package, but I already have a make
rules to build a deb package and check it with lintian, so I'm
not unprepared :)