Icon The Kermit Project   |   Now hosted by Panix.com
New York City USA   •   kermit@kermitproject.org
…since 1981

Kermit File Transfer Features

Frank da Cruz
fdc@columbia.edu
Created: 15 April 2022
Last update: Tue Apr 19 20:20:00 2022
In the 2020s, our choices for file transfer have narrowed considerably since the last decades of the 20th century, as has the diversity of computers and operating systems. Now, for all practical purposes, there are only two operating systems that matter: Windows, and Unix. Unix, of course, comes in hundreds of forms: MacOS, countless Linux variations, BSD, and so on.

The two major OS families have different text-file formats, so transferring files between them can be problematic. In Windows, a text file is a series of lines with each line terminated by Carriage Return (ASCII character number 13) and Line Feed (ASCII character number 10); ditto in VMS, a lesser known survivor from the 1970s and 80s. In Unix, however, text lines are separated by only Line Feed. When transferring text files between Unix and Windows the format must be converted or else the result will be problematic, varying from not looking right to not working.

Traditional file transfer protocols such as FTP and Kermit knew how to convert text files (X-, Y-, and ZMODEM did not). In FTP, you had to choose transfer mode to use for each file: text or binary. In Kermit, since 2001 (C-Kermit 8.0 and Kermit 95 2.0), each file was transferred in the right mode automatically so, for example, if you had a directory that contained a mixture of text and binary files, you could tell Kermit to transfer all the files at once with a command like "send *.*", and every file would arrive in the right format at the other end.

In general that is not the case with modern transfer methods; for example when you "download" a file with your Web browser it is always sent in binary mode.

Kermit file transfer features

The Kermit file-transfer protocol was designed from the beginning (1980-81) to be suitable for the widest variety of computers, operating systems, and communication methods. It has been implemented successfully on supercomputers, mainframes, minicomputers, microcomputers, desktops, laptops, tablets, and even handheld calculators. Not to mention assorted cash registers, industrial milling machines, and medical devices. Cell phones, I'm not sure, but there is an Android version! CLICK HERE for a list of Kermit implementations.

  1. Accurate transfers accomplished by error detection and correction, stop-and-wait protocol, or sliding windows with selective retransmission, or continuous streaming, depending on the type of connection. Plus the ability to tailor packet length and window size to the capacity and quality of the connection.
  2. Transfer of single files, groups of files (via "wildcards"), lists of files, or an entire directory tree in a single operation, even between unlike file systems (e.g. Windows, Unix, VMS).
  3. Automatic download: when you are using a Kermit program as your terminal emulator and the host sends a file to you with Kermit protocol, your terminal emulator automatically switches into file-transfer mode to receive the file and then switches back to terminal mode automatically when the transfer ends. Automatic upload is possible too, driven by the Kermit program at the far end.
  4. File attributes: Kermit transfers not just the file's name and contents, but also its creation date, size, permissions, and other attributes so they can be handled appropriately or preserved on the receiving computer. Attributes regarding the transfer itself are also included: the character encoding (for text files only) and the transfer mode (text or binary). No conversions are necessary when the two computers are "alike", but they are required fot text files when formats differ (e.g. between Windows and Unix).
  5. Text-file encoding conversion, e.g. between PC Code Pages, ISO 8859 encodings, various national character sets (like Russian KOI-8), and UTF-8. This is vital for text files written in languages other than English (but less important as UTF-8 — the Universal Character Set — sees wider adoption). See list of supported character sets.
  6. Automatic per-file text/binary mode selection. The file-attribute mechanism lets Kermit transfer files in the appropriate mode automatically not only in single-file transfers but also during a multifile transfer; each file is sent in the appropriate format along with a transfer-mode attribute so the receiver knows to convert incoming text files to its own format, if necessary, and to leave binary files alone. Examples of binary files include executable program images, JPG and other images, Microsoft Word documents, PDF files, and so on, which must not be altered in any way during transfer. Text files consist of lines of text — prose, computer program source code, HTML Web pages — that can have different formats (end-of-line marker, character encoding) on different platforms (Unix, Windows, etc).
  7. Options for handling filename collisions (overwrite, refuse, accept only if newer, append, backup, rename, etc).
  8. Recovery of interrupted transfers (binary files only between unlike filesystems; all files between like filesystems).
  9. Suitability to all types of connections: Internet, dialup modem, direct serial-port connections.
  10. High-speed streaming transfers on error-free connections such as TCP/IP or flow-controlled error-correcting modems.
  11. The ability to adapt to slow, noisy, and/or nontransparent communications channels such as modems, front ends, or other devices that have an "escape character" or sequence, and to receivers that can't accept long bursts of input. And the ability to adapt to 7-bit connections and to half-duplex connections (typical of 1970s-era IBM mainframes).
  12. Selection of files to be transferred not only by name, but also date ranges, size ranges, type (text or binary), and numerous other selection criteria, e.g. exception lists, in any combination.
  13. For transaction processing: the ability to automatically delete a file after (and only if) it was sent successfully and to move a successfully received file to a different location after (and only if) it was received successfully.
  14. The ability to send a file with a different name than it is stored with; ability to send a received file to a printer or to send it as email... etc etc.
  15. A client-server configuraton in which the human user (or script) controls everything from the client side.
  16. Speaking of scripts, the major Kermit programs (C-Kermit for Unix and VMS, Kermit 95 for Windows, and MS-DOS Kermit for MS-DOS) include a built-in script programming language for automation of any communication and/or file-transfer and management task. And almost any other task you can think of, such as this one.
Online references:
  1. The About Kermit web page.
  2. da Cruz, Frank, The Kermit Protocol Manual, June 1986.
  3. da Cruz, Frank, Kermit, A File Transfer Protocol, Digital Press, Burlington MA, 1987.
  4. da Cruz, Frank, and Christine M. Gianone, Using C-Kermit, Second Edition, Digital Press / Butterworth Heinemann, Newton MA (1997). C-Kermit 6.0 for Unix, VMS, and some other operating systems (Unix = Linux, MacOS, OpenBSD, NetBSD, FreeBSD, etc etc). Updates online at ckermit70.html for C-Kermit 7.0, ckkermit80.html for C-Kermit 8.0, and ckkermit90.html for C-Kermit 9.0.
  5. Kermit News issues, 1986-1995.
  6. Kermit 95 manual for K95 2.1.3 (online).
  7. Kermit Oral History Panel, Computer History Museum, 2012.
  8. Kermit Protocol 40th Anniversary, 29 April 2021.

The New Open-Source Kermit Project hosted by Panix.com /