Why commands can never afford to get it wrong in a version

April 10, 2010

Netcat is a nice, handy program; there are any number of circumstances in scripts and the like where what it does is just what I want. I don't use it, though. Instead, I have my own simple netcat-like program (called tcp) that I use instead.

There are a number of reasons for this, but one significant reason is that some versions of netcat get the end of file logic wrong. When they see end of file on standard input, they just close standard input; they don't signal the network server that no further input is coming. This behavior can be worked around in some but not all circumstances.

This netcat bug has since been fixed, but a buggy version of netcat made it into some Linux distributions and is still on some of the machines that I use. Since the buggy netcat exists on some machines, I can't trust netcat in general on an arbitrary machine and so I can't use netcat in any script that I want to run unedited on all of our machines; on some machines I will need to use a substitute that doesn't have the bug.

(Like many sysadmins I try to write generic scripts, especially seeing as we have a heavily NFS-based environment.)

And you know, if I've got to use a substitute on some machines it's simpler to use the substitute everywhere. I need to push around the substitute as well as the scripts, but once I've done that I have one less thing to remember, and I have a building block that works consistently everywhere.

This is why commands can't afford to get it wrong, ever. As far as sysadmins with lots of machines are concerned, if it's broken anywhere it's broken everywhere, and accidentally broken commands have a distressing habit of getting packaged and distributed on you. Once a flawed version of your command is out there in the field, well, see the deprecation schedule. I'm sure the netcat people had good intentions, but the end result is that netcat often might as well not exist for me.

(Actually, it's really too late in general once sysadmins start having to use a substitute. I'm extremely unlikely to revise my scripts in three or four years to start using netcat instead of my substitute, given that everything still works fine and it would thus be pointless make-work.)

PS: I'm aware that netcat has many, many more features than acting as a simple network copy command. But I generally don't need those features and I do periodically need a network copy command.


Comments on this page:

From 74.195.225.199 at 2010-04-10 22:06:24:

Any clue how socat does in that regard? I never use netcat because I have socat, and it's easier to stick to one tool.

Random

By cks at 2010-04-12 11:12:54:

The version of socat that I have on one machine here works right, but this machine also has a working version of netcat. The socat manpage has an explicit discussion of what socat does when things start shutting down, which encourages me to think that the authors have been thinking about this from the start.

(I'll have to remember socat more often; despite the goofy command line syntax, it can do some useful things.)

Written on 10 April 2010.
« The processing flow of a network copying program
The comedy potential inherent in people reusing your address space »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Sat Apr 10 01:07:20 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.