I continue to be amazed and dismayed by the number of people who seem to want to sort IPv4 addresses directly in their human-readable printed character representation using a complex multi-field numeric sort instead of in their natural internal binary representation. The overhead of the former method is excessive when compared to the latter, even including conversion from and to the human readable form as may be needed for the latter, even if you do it twice into another temporary file to be able to use "sort" on the command line or in a script. :-)

There are a lot of situations where we maintain lists of IPv4 addresses in their textual representations; one obvious case is firewall configurations. Representing these in plain text and sorting them makes it much easier for people to keep track of what is and isn't included and to update things in a comprehensible way.

(I assume that when these firewall configurations are loaded into memory by the kernel, the IP addresses and CIDR ranges are encoded into binary and maintained in an efficient data structure, but that's not what I care about when it comes to configuration files. Configuration files are for people first and computers second, just like programming languages.)

Yes, but why would you work so hard, and make the computer work so hard, to do complex multi-column numeric sorts when it is (nearly) trivial to convert to 32-bit internal numeric form, do the sort, and then convert back to quad-dotted form?

'sort -V' is already there and presumably generally useful for more than IPv4 addresses. If it's inherited from ls as the coreutils documentation suggests, sorting IPv4 addresses is probably not its common usage case in general.

If I was sorting ten million IPv4 addresses on a frequent basis I might write custom code. But if I had ten million IPv4 addresses that I needed to sort on a regular basis, they would probably not be held in text at all. The relevant XKCD applies here (and also).

I had never heard of 'sort -V' until today. :-)

(it's definitely not in posix nor in NetBSD, though now FreeBSD has it, and OpenBSD has already taken it from FreeBSD, then it is probably only a matter of time until it is in NetBSD too)

I admit doing the conversion to/from plain integers is a bit of a pain to type in an AWK one-liner every time you need it, but a purpose-built converter is really easy! :-)

Of course it's not all that difficult to get a modern POSIX 'sort' to do it all with appropriate use of '-t', '-n', and '-k' -- though more work to type than "ip2n < file | sort -n | n2ip"

The question is how easy it is for the user to ask for sorting by IP, and sort -V plainly beats doing it by hand in the cases where sort -V is a plausible choice.

When you’re SSHed into another machine without your usual ~/bin and all you need to do is sort one text file with IP addresses, it’s completely beside the point how easy it is to write a purpose-built converter. Nobody is going to start typing out a program for the job if they can just type sort -V, at least not just because of the waste of making the computer spend 1200 nanoseconds on the job instead of 12.

If you go to the trouble of putting a purpose-built IP sorter in the base system (be it OS vendor upstream or your own local standard OS image or whatever) then sure… it might make sense to use that. But again, once sort -V is already in there, why bother?

Well, maybe because the code is hot enough for the wasted cycles to matter. But that’s not a scenario where sort -V is applicable; you’re not likely to be using the shell then anyway.

Maybe you’re talking about people writing complex sorts in something more powerful than shell, where it’s not typically as easy to express sorting IPs in their string form as “sort -V”. There it’s typically much less code to convert to and sort binary IPs, and in that case you have a very good point.

But neither of these cases are, it seems to me, what Chris was talking about.

None of the machines I do any sys-admin work on these days (macOS and NetBSD) have "sort -V"

If I'm stuck needing to sort a list of IP addresses on some machine where 'sort' is old/incapable then I'd happily type out the slightly awkward AWK code needed to convert IP addresses to/from integers. Every version of AWK can do it, and every version of 'sort' has '-n'. It's really not that difficult to figure out and type out every time it's needed, though I do tend to be one of those people who will copy such things into shell command aliases, or tiny script files.

Then again I might copy/paste some existing C (or Go) code that does the whole job and more, assuming of course there's a C (or Go) compiler on the target machine, and/or I can generate binaries elsewhere that'll run on it. For this particular task I have used this in the past: https://github.com/alaska/cidr-convert

Or I might copy the list to my local machine and sort it, etc., with appropriate tools I'm familiar with. I've been doing that kind of thing, even for relatively large data sets, for literally decades now (ever since my normal working environment gave me the ability to copy and paste between two terminal windows -- which has been far longer than I could normally copy files directly between remote filesystems).

I am personally wary of using awk for anything involving large integers. Awk theoretically works in floating point numbers, so if the precision of its floating point numbers is not large enough, problems will ensue with your large integers. (I actually had this happen to me long ago with Unix timestamps, which is why it has stuck with me ever since.)

Modern versions of awk may use floating point types large enough to avoid this for the 32-bit integers that are IPv4 addresses, or they may be clever enough to keep integer values as actual integers until they have to be converted to a potentially inexact form, but in either case I feel that I'm gambling. I would much rather work with something (such as Python) where I can be completely sure that my integers are staying exact.

Well on modern hardware any decent version of AWK, including pre-arbitrary-precision GNU awk, will support exact integers in the range of +/- 2^53.

BTW, I do agree 100% with your original sentiment in this posting, i.e. that, if available, 'sort -V' is a cool trick for sorting IPv4 addresses in their normal quad-dotted human representation.

(The most painful thing about using AWK for converting IP addresses is that it doesn't have any bitwise operators.)