You Say 'Jump,' Kermit Asks, 'How High?'
back, children, to the distant days of 1981. Things in the computing world
were different then. All the real work was done on mainframes and minicomputers,
through either a direct or dial-up terminal connection. Personal computing
meant the Apple II or a machine running CP/M (or an Apple II running CP/M
on an 8080 add-in card). Nobody outside the world of personal computing
hobbyists had ever heard of Microsoft Corp. of Redmond, WA, which was
best known for its BASIC interpreter.
Hardly anybody but defense contractors
(and some universities) had ever heard of ARPANET, the ancestor of the
Internet. The birth of the Web as a means for high-energy physics researchers
to make information widely available was still a decade away. Various
proprietary networking protocols, like DECnet, had been around for some
time, but you couldn't usually get machines from different vendors to
talk the same protocols, unless all the machines were pretending to be
People needed to share files, log
into one machine from another, transfer data between machines that couldn't
read each other's tapes or disks; in those days, there was no standardized
or compatible media. And people who had personal computers didn't see
why they should also have to have terminals on their desks just to communicate
This was the year that Armonk, NY-based
IBM Corp. introduced the PC, legitimizing the idea of a desktop computer
in the minds of business decision makers. If IBM was selling the things,
they weren't just toys. (By today's standards, a 4.77MHz PC with 64KB
that's "KB", not "MB" of RAM, no hard
drive, a single 5.25-inch floppy drive and a monochrome monitor is just
a toy, or maybe a door stop, but these were real business machines then.)
So here are PCs getting onto business
desktops and needing to talk to the mainframes and micros and other PCs.
The question was: How do you do it?
Kermit to the rescue. (Kermit was
named, with permission, for the famous Kermit The Frog from Jim Henson's
Muppets.) A project of Columbia University, Kermit started out in 1981
as a file transfer and terminal emulation utility. It wasn't the only
one Modem7, XMODEM and others spring to mind but it was
quite full-featured even at the beginning, supported many hardware and
software platforms, and has been under continuous development for the
past 20 years.
Terminal emulation involves, as the
name implies, pretending to be a terminal. This means not only taking
user keystrokes from the local keyboard and passing them on to a host,
but also intercepting the stream of responses from the host, which includes
special codes that give instructions to the terminal the host thinks it's
talking to; examples include "put the cursor in the upper right hand
corner" or "turn reverse video on starting here and leave it
on until you get the command to turn it off."
An emulator has to not only understand,
but implement, those codes, often called "escape sequences"
because they're preceded by a special character that says a command is
coming. If your minicomputer is expecting to talk to a terminal and you
have a PC on your desk, you'd better have a terminal emulator.
Kermit is the name of the program,
but it's also the name of a file transfer protocol implemented in the
program and implemented, though usually less well, in some commercial
products as well.
To initiate a file transfer from a
PC to a host, you could fire up Kermit, have it talk out a serial port
(either one with a direct connection to the host or one that was hooked
up to a modem; Kermit understands modems and knows how to dial them) and
connect to the host as a normal user.
You'd log in and once you got to the
host's command prompt, you could tell the host to run Kermit, issue the
command telling the host Kermit to accept remote control, drop back to
your local Kermit and tell it to send or get files. If you had a DOS PC,
you could run Kermit and tell it to listen for commands on one of
the serial ports, thus making it ready to swap files.
In the early 1980s, the Kermit software
was primarily distributed on tapes, for which the sellers charged enough
to recover the cost of manufacture. The source code was available, and
the user community ported the software to many additional platforms. The
project was, in many ways, prototypical of the free software movement,
but it predated the free software/open source discussion, came before
the GNU Public License or the PERL Artistic License, and was 10 years
old already when Linus Torvalds started kernel hacking.
With the rise of the Internet, the
Kermit Project sold many fewer tapes since people could just download
the software and needed to develop another funding model. Now, if you
get the software, you are expected to buy the manual, which has been through
several editions. But the source code is a free download, the software
itself is a free download, and you don't have to buy a copy of the manual
for every machine you use it on.
Comes Of Age
There is a different policy for Kermit95,
which was developed to run under Windows 95 and also supports OS/2, Windows
95/98/ME/NT and probably 2000 as well. Here, you are expected to buy a
license. You can buy the product itself in computer stores, or take advantage
of generous site license terms. This is GUI-enhanced graphical Kermit,
not just a port of command-line Kermit, and as such, it's reasonable to
charge money for the additional development effort. MS-DOS Kermit (for
DOS and Windows 3.x) is still free. The Kermit that runs on every other
platform is C-Kermit, soon to be at version 7.1.
All this stuff about file transfer
and terminal emulation might be irrelevant to you. If you're on the Net,
you've probably got telnet and File Transfer Protocol (FTP), which pretty
well cover this. So why do we care about Kermit now?
First, because it does a really, really
good job at file transfer and terminal emulation. If you're going to telnet
into a VMS-based machine, for example, and want to use the editor or a
full-screen data-entry application, you need a pretty complete terminal
emulator the telnet that comes with Windows does a lousy job of
pretending to be a VT-100 terminal.
As for a file transfer, if you've
got Kermit on both ends, you can transfer file protections even between
unlike systems. That is, if you're copying something that the whole world
has read access to from a UNIX system, the protection it'll end up with
on a VMS system is the same. Kermit is also willing to transfer entire
directory trees and keep the hierarchy intact, again, even between unlike
systems, which not all FTP clients and servers can do. It doesn't even
require that the transfer be over a serial line; Kermit's smart enough
to make a connection over TCP/IP and run the same way.
Second, it does a lot more than file
transfer and terminal emulation. There is a very sophisticated, built-in
scripting language that combines with the other capabilities to allow
you to do a variety of things.
Do you want your Linux box to page
you if it's almost out of disk space? You can use UNIX system management
tools to detect the condition and Kermit to issue an alphanumeric page.
Through the scripting language and its mastery of modems, it implements
the Telocator Alphanumeric Protocol (TAP), widely supported by paging
A lot of paging companies will just
let you e-mail your page to them over the Internet, but if you want to
get paged because your machine fell off the Internet, that won't do you
much good you need to dial out, and Kermit knows how.
Another problem that comes up in real
life fairly often is the necessity to automate an FTP file transfer. Some
systems prepare a file that you need to process on the system you manage.
For example, you need to fetch and merge the logs from several different
Web servers. You can get the logs with FTP, but if something went wrong
you might end up with the previous log, which would pollute your merged
log file and mess up the statistics you're going to produce.
FTP clients are usually pretty bad
at telling you what went wrong, and most of them don't have very robust
scripting. Kermit now has a built-in FTP client, which is fully scriptable
using the same language as the other capabilities. It already had a telnet
client, which made scripting log-in sessions pretty straightforward.
Kermit runs on just about every UNIX
known to mankind, and all sorts of other systems: VMS for VAX and Alpha,
AOS/VS, the IBM operating systems, RSX-11, AmigaOS, Plan9, BeOS and on
and on. Ubiquity, robustness and capability mean that Kermit should be
in every system manager's tool kit. C-Kermit 7.0 and later can be bundled
with any open source operating system distribution for free, although
other commercial distribution requires special licensing and some payment.
With constant development, the Kermit
Project makes sure that this old frog can keep learning new tricks.
Winston is the computer systems administrator for Stanford Synchrotron
Radiation Laboratory, a Menlo Park, CA, research laboratory. He is a
former editor-at-large of UNIX World. He is involved with databases,
Web servers, e-mail, application development and system administration.
He has been writing about computers since 1983. He can be reached at