When You Say 'Jump,' Kermit Asks, 'How High?'

By Alan Winston

      Think 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 IBM mainframes.
      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 with mainframes.
      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.

Kermit 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 companies.
      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.