G - K e r m i t   2 . 0 1

Update 23 September 2023... I got access to Bell UNIX V7 (1979) and was able to upload the G-Kermit source to it via the "cat > xxx.c / transmit xxx.c / Ctrl-D" method for all 6 modules plus the makefile, which was remarkably smooth and painless. G-Kermit V2 compilation failed because of #includes for malloc.h, stdlib.h, etc. Adding a V7 target to the makefile and #ifndef V7 around the #includes made no difference. I uploaded version 1 (which does not #include not-found headers) the same way, and it totally misinterpreted the makefile. V7 make is apparently very different, but "man make" on this machine is for a 1990s-vintage gmake. So I tried "cc -o gwart.o gwart.c" and cc (version unknown) said "Failed: would overwrite gwart.o", even though there was no gwart.o on the disk. Then I tried simply "cc gwart.c" and this produced an a.out which turned out to be the gwart executable, which worked. I wonder if I can figure out how to build the other modules and combine them into the gkermit executable.

1. OVERVIEW

This software is OSI Certified Open Source Software.
OSI Certified is a certification mark of the Open Source Initiative.

G-Kermit is:

• Fast
• Small
• Portable
• Easy to use
• Interoperable
• Low-maintenance
• Stable and reliable

Features include:

• Text and binary file transfer on both 7-bit and 8-bit connections
• Files can be transferred singly or in groups
• Automatic startup configuration via GKERMIT environment variable
• Configurability as an external protocol

Kermit protocol features include:

• Automatic peer recognition
• Streaming on reliable connections
• Selectable packet length, 40 to 9000 bytes (4000 default)
• Single shifts for 8-bit data on 7-bit connections
• Control-character prefixing for control-character transparency
• Control-character unprefixing for increased speed (incoming only)
• Compression of repeated bytes
• Per-file and batch cancellation

Features selectable on command line:

• Text or binary mode transfer
• Filename conversion on/off
• Filename collision backup versus overwrite
• Keep or discard incompletely received files
• Packet length
• Packet timeout
• Flow control
• Parity
• Streaming
• Messages
• Debugging

Features not included (see Section 14):

• Making connections
• Character-set translation
• Interactive commands and scripting
• File date-time stamps

2. INVOKING G-KERMIT

$ stty crtscts

(where "$ " is the shell prompt) for RTS/CTS hardware flow control, or:

$ stty ixon ixoff

for Xon/Xoff "software" flow control. When you have a network connection, flow control is usually nothing to worry about, since the network protocol (TCP or X.25) takes care of it automatically, but on certain platforms (such as HP-UX) the TCP/IP Telnet or Rlogin server uses this for flow control between itself and the underlying pseudoterminal in which your session runs, so Xon/Xoff might be required for these sessions too.

The G-Kermit binary is called "gkermit". It should be stored someplace in your Unix PATH, such as /usr/local/bin/gkermit or somewhere in the /opt tree on System V R4. To run G-Kermit, just type "gkermit" followed by command-line options that tell it what to do. If no options are given, G-Kermit prints a usage message listing the available options:

G-Kermit 2.01, The Kermit Project, 2021-11-15: POSIX.
Usage:  gkermit [ options ]
Options:
 -r      Receive files
 -s fn   Send files
 -g fn   Get files from server
 -a fn   As-name for single file
 -i      Image (binary) mode transfer
 -T      Text mode transfer
 -P      Path/filename conversion disabled
 -w      Write over existing files with same name
 -K      Keep incompletely received files
 -p x    Parity: x = o[dd],e[ven],m[ark],s[pace],n[one]
 -e n    Receive packet-length (40-9000)
 -b n    Timeout (sec, 0 = none)
 -x      Force Xon/Xoff (--x = Don't force Xon/Xoff)
 -S      Disable streaming
 -X      External protocol
 -q      Quiet (suppress messages)
 -d [fn] Debug to ./debug.log [or specified file]
 -h      Help (this message)
Web:   http://www.kermitproject.org/gkermit.html
Email: kermit@kermitproject.org

If an option takes an argument, the argument is required; if an option does not take an argument, no argument may be given (exceptions: -d may or may not take an argument; -s can take one or more arguments).

The action options are -r, -s, and -g. Only one action option may be given. If no action options are given, G-Kermit does nothing (except possibly printing its usage message or creating a debug.log file). Here are some examples (in which "$ " is the shell prompt):

$ gkermit -s hello.c       Sends the hello.c file.
$ gkermit -s hello.*       Sends all hello.* files.
$ gkermit -r               Waits for you to send a file to it.
$ gkermit -g hello.c       Gets the hello.c file from your computer.
$ gkermit -g \*.c          Gets all *.c files from your computer.

Options that do not take arguments can be "bundled" with other options. An option that takes an argument must always be followed by a space and then its argument(s). Examples:

$ gkermit -is hello.o      Sends hello.o in binary mode.
$ gkermit -dSr             Receives with debugging and no streaming.

G-Kermit's exit status is 0 if all operations succeeded and 1 if there were any failures. If a group of files was transferred, the exit status is 1 if one or more files were not successfully transferred and 0 if all of them were transferred successfully.

3. COMMAND-LINE OPTIONS

You may supply options to G-Kermit on the command line or through the GKERMIT environment variable, which can contain any valid gkermit command-line options. These are processed before the actual command-line options and so can be overridden by them. Example for bash or ksh, which you can put in your profile if you want to always keep incomplete files, suppress streaming, suppress messages, and use Space parity:

  export GKERMIT="-K -S -q -p s"

G-Kermit's options are compatible with C-Kermit's, with the following exceptions:

-P (available only in C-Kermit 7.0 and later)
-K (currently not used in C-Kermit)
-b (used in C-Kermit for serial device speed)
-S (used in C-Kermit to force an interactive command prompt)
-x (used in C-Kermit to start server mode)
--x (currently not used in C-Kermit)
-X (currently not used in C-Kermit)

4. THE MECHANICS OF FILE TRANSFER

Sending Files

  $ gkermit -Ts oofa.txt

it pauses for a second and then sends its first packet. What happens next depends on the capabilities of your terminal emulator:

• If your emulator supports Kermit "autodownloads" then it receives the file automatically and puts you back in the terminal screen when done.

• Otherwise, you'll need to take whatever action is required by your emulator to get its attention: a mouse action, a keystroke like Alt-x, or a character sequence like Ctrl-\ or Ctrl-] followed by the letter "c" (this is called "escaping back") and then tell it to receive the file. When the transfer is complete, you might have to instruct your emulator to go back to its terminal screen.

During file transfer, most terminal emulators put up some kind of running display of the file transfer progress.

Receiving Files

Getting Files

5. INTERRUPTING FILE TRANSFER

When G-Kermit is in packet mode and your terminal emulator is in its terminal screen, you can also type three (3) Ctrl-C characters in a row to make G-Kermit exit and restore the normal terminal modes.

6. TEXT AND BINARY TRANSFER MODE

When sending files in text mode, G-Kermit converts the record format to the common one that is defined for the Kermit protocol, namely lines terminated by carriage return and linefeed (CRLF); the receiver converts the CRLFs to whatever line-end or record-format convention is used on its platform. When receiving files in text mode, G-Kermit simply strips carriage returns, leaving only a linefeed at the end of each line, which is the Unix convention.

When receiving files, the sender's transfer mode (text or binary) predominates if the sender gives this information to G-Kermit in a Kermit File Attribute packet, which of course depends on whether your terminal emulator's Kermit protocol has this feature. Otherwise, if you gave a -i or -T option on the gkermit command line, the corresponding mode is used; otherwise the default mode (binary) is used.

Furthermore, when either sending or receiving, G-Kermit and your terminal emulator's Kermit can inform each other of their OS type (Unix in G-Kermit's case). If your emulator supports this capability, which is called "automatic peer recognition", and it tells G-Kermit that its platform is also Unix, G-Kermit and the emulator's Kermit automatically switch into binary mode, since no record-format conversion is necessary in this case. Automatic peer recognition is disabled automatically if you include the -i (image) or -T (text) option.

When sending, G-Kermit sends all files in the same mode, text or binary. There is no automatic per-file mode switching. When receiving, however, per-file switching occurs automatically based on the incoming Attribute packets, if any (explained below), that accompany each file, so if the file sender switches types between files, G-Kermit follows along.

7. PATHNAMES

G-Kermit uses the full pathname given to find and open the file, but then strips the pathname before sending the name to the receiver. For example:

  $ gkermit -s /etc/hosts

results in an arriving file called "HOSTS" or "hosts" (the directory part, "/etc/", is stripped; see next section about capitalization). However, if a pathname is included in the -a option, the directory part is not stripped:

  $ gkermit -s /etc/hosts -a /tmp/hosts

This example sends the /etc/hosts file but tells the receiver that its name is "/tmp/hosts". What the receiver does with the pathname is, of course, up to the receiver, which might have various options for dealing with incoming pathnames.

When RECEIVING a file, G-Kermit does NOT strip the pathname, since incoming files normally do not include a pathname unless you told your terminal to include them or gave an "as-name" including a path when sending to G-Kermit. If the incoming filename includes a path, G-Kermit tries to store the file in the specified place. If the path does not exist, the transfer fails. The incoming filename can, of course, be superseded with the -a option.

8. FILENAME CONVERSION

When receiving a file, if the name is all uppercase, G-Kermit converts it to all lowercase. If the name contains any lowercase letters, G-Kermit leaves the name alone. Otherwise G-Kermit accepts filename characters as they are, since Unix allows filenames to contain practically any characters.

If the automatic peer recognition feature is available in the terminal emulator, and G-Kermit recognizes the emulator's platform as Unix, G-Kermit automatically disables filename conversion and sends and accepts filenames literally.

You can force literal filenames by including the -P option on the command line.

9. FILENAME COLLISIONS

To defeat the backup feature and have incoming files overwrite existing files of the same name, include the -w (writeover) option on the command line.

If G-Kermit has not been given the -w option and it fails to create a backup file, the transfer fails.

10. KERMIT PROTOCOL DETAILS

Block check

G-Kermit uses the 3-byte, 16-bit CRC by default. If the other Kermit does not agree, both Kermits automatically drop down to the single-byte 6-bit checksum that is required of all Kermit implementations.

Attributes

When sending files, G-Kermit conveys the file transfer mode and file size in bytes to the receiver in an Attribute (A) packet if the use of A-packets was negotiated. This allows the receiver to switch to the appropriate mode automatically, and to display the percent done, estimated time left, and/or a thermometer bar if it has that capability. When receiving, G-Kermit looks in the incoming A-packet, if any, for the transfer mode (text or binary) and switches itself accordingly on a per-file basis.

Handling of the Eighth Bit

G-Kermit normally treats the 8th bit of each byte as a normal data bit. But if you have a 7-bit connection, transfers of 8-bit files fail unless you tell one or both Kermits to use the appropriate kind of parity, in which case Kermit uses single-shift escaping for 8-bit bytes. Generally, telling either Kermit is sufficient; it tells the other. Use the -p option to tell G-Kermit which parity to use. Locking shifts are not included in G-Kermit.

Control-Character Encoding

G-Kermit escapes all control characters when sending (for example, Ctrl-A becomes #A). When receiving, it accepts both escaped and bare control characters, including NUL (0). However, unescaped control characters always present a danger, so if uploads to G-Kermit fail, tell your terminal emulator's Kermit to escape most or all control characters (in C-Kermit and Kermit 95 the command is SET PREFIXING CAUTIOUS or SET PREFIXING ALL).

Packet Length

All legal packet lengths, 40-9000, are supported although a lower maximum might be imposed on platforms where it is known that bigger ones don't work. When receiving, G-Kermit sends its receive packet length to the sender, and the sender must not send packets any longer than this length. The default length for most platforms is 4000 and it may be overridden with the -e command-line option.

Sliding Windows

G-Kermit does not support sliding windows. Streaming is used instead. If the other Kermit bids to use sliding windows, G-Kermit declines.

Streaming

If the terminal emulator's Kermit informs G-Kermit that it has a reliable connection (such as TCP/IP or X.25), and the emulator's Kermit supports streaming, then a special form of the Kermit protocol is used in which data packets are not acknowledged; this allows the sender to transmit a steady stream of (framed and checksummed) data to the receiver without waiting for acknowledgements, allowing the fastest possible transfers. Streaming overcomes such obstacles as long round trip delays, unnecessary retransmissions on slow network connections, and most especially the TCP/IP Nagle and Delayed ACK heuristics which are deadly to a higher-level ACK/NAK protocol. When streaming is in use on a particular connection, Kermit speeds are comparable to FTP. The drawback of streaming is that transmission errors are fatal; that's why streaming is only used on reliable connections, which, by definition, guarantee there will be no transmission errors. However, watch out for the relatively rare circumstance in which the emulator thinks it has a reliable connection when it doesn't -- for example a Telnet connection to a terminal server, and a dialout from the terminal server to the host. Use the -S option on the command line to defeat streaming in such situations.

Using all defaults on a TCP/IP connection on 10BaseT (10Mbps) Ethernet from a modern Kermit program like C-Kermit 7.0 or Kermit 95, typical transfer rates are 150-1000Kcps, depending on the speed of the two computers and the network load.

11. PROBLEMS, BUGS, ERRORS

• Make sure your terminal emulator is not unprefixing control characters; various control characters might cause trouble along the communication path. When in doubt, instruct the file sender to prefix all control characters (e.g. SET PREFIXING ALL).

• Make sure your Unix terminal is conditioned for the appropriate kind of flow control.

• Use command-line options to back off on performance and transparency; use -S to disable streaming, -e to select a shorter packet length, -p to select space or other parity, -b to increase or disable the timeout, and/or establish the corresponding settings on your emulator.

When receiving files in text mode, G-Kermit strips all carriage returns, even if they aren't part of a CRLF pair.

If you have a TCP/IP connection (e.g. Telnet or Rlogin) to Unix from a terminal emulator whose Kermit protocol does not support streaming, downloads from G-Kermit are likely to be as much as 10 or even 100 times slower than uploads if the TCP/IP stack engages in Nagle or Delayed ACK heuristics; typically, when your terminal emulator's Kermit protocol sends an acknowledgment, the TCP stack holds on to it for (say) 1/5 second before sending it, because it is "too small" to send right away.

As noted in Section 9, the backup prefix is not guaranteed to be the highest number. For example, if you have files oofa.txt, oofa.txt.~1~, and oofa.txt.~3~ in your directory, and a new oofa.txt file arrives, the old oofa.txt is backed up to oofa.txt.~2~, rather than oofa.txt.~4~ as you might expect. This is because gkermit lacks directory reading capabilities, for reasons noted in Section 14, and without this, finding the highest existing backup number for a file is impractical.

If you send a file to G-Kermit with streaming active when the connection is not truly reliable, all bets are off. A fatal error should occur promptly, but if huge amounts of data are lost, G-Kermit might never recognize a single data packet and therefore not diagnose a single error; yet your terminal emulator keeps sending packets since no acknowledgments are expected; the transfer eventually hangs at the end of file. Use -S on G-Kermit's command line to disable streaming in situations where the terminal emulator requests it in error.

You can use G-Kermit's debug log for troubleshooting; this is useful mainly in conjunction with the source code. But even if you aren't a C programmer, it should reveal any problem in enough detail to help pinpoint the cause of the failure. "gkermit -d" (with no action options) writes a short debug.log file that shows the build options and settings.

The debug log is also a packet log; to extract the packets from it, use:

  grep ^PKT debug.log

Packets in the log are truncated to avoid wrap-around on your screen, and they have the Ctrl-A packet-start converted to ^ and A to avoid triggering a spurious autodownload when displaying the log on your screen.

In certain circumstances it is not desirable or possible to use -d to create a log file called debug.log in the current directory; for example, if you don't have write access to the current directory, or you already have a debug.log file that you want to keep (or transfer). In this case, you can include a filename argument after -d:

  gkermit -d /tmp/testing.log -s *.c

(This is an exception to the rule that option arguments are not optional.)

12. BUILDING G-KERMIT

When I wrote G-Kermit in 1999, I wanted it to serve as an example of a program that would last forever, and not need constant "updates" and "upgrades" and "patches" which are the hallmark of modern software culture, where stability is a forgotten concept in programming language design just as backwards compatibility is in operating system and library releases. But the world keeps changing out from under G-Kermit and every other software program on every modern platform (unlike, for example, the IBM OS/MVS operating system for which I wrote software in 1970-something that has never needed upgrades or updates or patches to keep working decade after decade). Anyway, in Unix the biggest change affecting G-Kermit is migration of the errno variable from a simple int to some kind of object or macro defined in a header file. Thus the most common complaint from those trying to build G-Kermit on Linux or wherever is fatal compilation or link-time errors involving errno. Sometimes 'errno' is the obvious culprit but increasingly it's not, as in this message from the Red Hat RHEL6 64-bit linker in 2016:

/usr/bin/ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in gkermit.o /lib64/libc.so.6: could not read symbols: Bad value

The solution is to include:

KFLAGS="-DERRNO_H"

among the compilation flags (this has always been documented towards the end of this web page, but most people don't read that far). Other errors are increasingly reported that are solved by including ever more header files in gkermit.h or elsewhere, e.g.:

#include <malloc.h>
#include <string.h>
#include <stdlib.h>

I'm not inclined to make a new release just because of bureaucratic reshuffling of header files or requirement of prototypes where they weren't required before, because disregard for stability should not be rewarded. A program, once written, should stay written, so the programmer can go on to something new, rather than writing the same program over and over and over simply to "comply" with whatever new thing somebody dreamed up. Anyway, G-Kermit is GPL so anybody can change it however they want. (Yes, the whole thing could just be engineered for autoconf, but autoconf is not available on all the platforms where G-Kermit is built.)

Postscript, May 2021... G-Kermit, which when I wrote it in 1999, compiled with zero warnings or errors on dozens of different platforms, now gets 203 warnings on Netbsd 9.0, but generates a functional executable. On Red Hat Enterprise Linux Server release 6.10, it gets 24 warnings about incompatible implicit declaration of built-in functions and finally dies with "/usr/bin/ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in gkermit.o /lib64/libc.so.6: could not read symbols: Bad value collect2: ld returned 1 exit status". On Ubuntu 20.04.1, it gets 30 warnings such warnings and dies the same way.

I'm beyond disgusted. There is no point in "fixing" G-Kermit to "comply" with the latest "standard", because then a year or two later the same thing will happen again.

The source files are:

  makefile   The build procedure
  gwart.c    Source code for a mini-lex substitute
  gproto.w   G-Kermit protocol state machine to be preprocessed by gwart
  gkermit.h  G-Kermit header file
  gkermit.c  G-Kermit main module and routines
  gcmdline.c G-Kermit command-line parser
  gunixio.c  Unix-specific i/o routines

A simple makefile is provided, which can be used with make or gmake. There are three main targets in the makefile:

posix

Build for any POSIX.1 compliant platform (termios). This is the default target, used if you type "make" (or "gmake") alone. This target works for most modern Unixes, including GNU/Linux, FreeBSD, OpenBSD, NetBSD, BSDI, HP-UX, Solaris, SunOS, Unixware, AIX, etc.

sysv

Build for almost any AT&T System V platform (termio). Examples include AT&T Unix releases, e.g. for the AT&T 7300, HP-UX versions prior to 7.00.

bsd

Build for any BSD (pre-4.4) or Unix V7 platform (sgtty). Examples include NeXTSTEP 3.x, OSF/1, Ultrix-11, and 4.3BSD or earlier.

Note that the target names are all lowercase; "posix" is the default target (the one used if you just type "make"). If the build fails with a message like:

gunixio.c: 65: Can't find include file termios.h
*** Error code 1

then try "make sysv" or "make bsd". See the build list below for examples.

Some special build targets are also provided:

sysvx

Like sysv but uses getchar()/putchar() for packet i/o rather than buffered nonblocking read()/write(); this is necessary for certain very old System V platforms (see description of USE_GETCHAR below).

stty

When none of the other targets compiles successfully, try this one, which runs the external stty program rather than trying to use API calls to get/set terminal modes (system("stty raw -echo") and system("stty -raw echo")).

Several maintenance/management targets are also included:

clean

Remove object and intermediate files.

install

Install gkermit (read the makefile before using this).

uninstall

Uninstall gkermit from wherever "make install" installed it.

[g]make CC=gcc [target]

No other tools beyond make, the C compiler and linker, a short list of invariant header files, and the standard C library are needed or used. The resulting binary should be 100K or less on all hardware platforms (and 64K or less on most; see list below).

You may also specify certain build options by including a KFLAGS clause on the make command line, e.g.:

make "KFLAGS=-DSETXONXOFF -DEXTRADEBUG" sysv

By default, nonblocking buffered read() is used for packets; this technique works on most platforms but other options -- USE_GETCHAR and DUMBIO -- are provided when it doesn't work or when nonblocking i/o is not available.

The build options include:

NOSTDLIB

(New in G-Kermit 2.01) If your build fails because <stdlib.h> can't be found, which should happen only on very old Unix OS's (/usr/include/stdlib.h is required on most 21st Century Unixes for its sleep() prototype)... If this happens use KFLAGS=NOSTDLIB on the 'make' command line, e.g.:

make "KFLAGS=-DNOSTDLIB" posix

__STDC__

Include this when the compiler requires ANSI prototyping but does not define __STDC__ itself. Conversely, you might need to include -U__STDC__ if the compiler defines __STDC__ but does not support minimum ANSI features.

ULONG=long

Include this if compilation fails with "unknown type: unsigned long".

CHAR=char

Include this if compilation fails with "unknown type: unsigned char".

SMALL

Define this when building on or for a "small" platform, for example a 16-bit architecture.

USE_GETCHAR

Specifies that packet i/o should be done with (buffered) getchar() and putchar() rather than the default method of nonblocking, internally buffered read() and write(). Use this only when G-Kermit does not build or run otherwise, since if the default i/o code is not used, G-Kermit won't be able to do streaming.

DUMBIO

Specifies that packet i/o should be done with blocking single-byte read() and write(). Use this only when G-Kermit doesn't build or run, even with USE_GETCHAR.

MAXRP=nnn

Change the maximum receive-packet length to something other than the default, which is about 9000. You should change this only to make it smaller; making it bigger is not supported by the Kermit protocol.

DEFRP=nnn

Change the default receive packet length to something other than the default, which is 4000. Making it any bigger than this is not advised.

TINBUFSIZ=nnn

On builds that use nonblocking buffered read(), override the default input buffer size of 4080.

SETXONXOFF

On some platforms, mainly those based on System V R4 and earlier, it was found that receiving files was impossible on TCP/IP connections unless the terminal driver was told to use Xon/Xoff flow control. If downloads work but uploads consistently fail (or fail consistently whenever streaming is used or the packet length is greater than a certain number like 100, or 775), try adding this option. When gkermit is built with this option, it is equivalent to the user always giving the -x option on the command line. (Most versions of HP-UX need this; it is defined automatically at compile time if __hpux is defined.)

ERRNO_H

#include <errno.h> (rather than "extern int errno;"). Include this if you get Unresolved Extern complaints about errno at link time.

SIG_V

The data type of signal handlers is void. This is set automatically for System V and POSIX builds.

SIG_I

The data type of signal handlers is int. This is set automatically for BSD builds.

NOGETENV

Add this to disable the feature in which G-Kermit gets options from the GKERMIT environment variable.

NOSTREAMING

Add this to disable streaming.

EXTRADEBUG

This adds a lot (a LOT) of extra information to the debug log regarding packet and character-level i/o.

"Passing arg 2 of `signal' from incompatible pointer"

(or "Argument incompatible with prototype"): Because no two Unix platforms agree about signal handlers. Harmless because the signal handler does not return a value that is used. We don't want to open the door to platform-specific #ifdefs just to silence this warning. However, you can include -DSIG_I or -DSIG_V on the CC command line to override the default definitions.

"blah declared but never used":

Some function parameters are not used because they are just placeholders or compatibility items, or even required by prototypes in system headers. Others might be declared in system header files (like mknod, lstat, etc, which are not used by G-Kermit).

"Do you mean equality?":

No, in "while ((c = *s++))" the assignment really is intentional.

"Condition is always true":

Yes, "while (1)" is always true.

"Flow between cases":

Intentional.

"No flow into statement":

In gproto.c, because it is a case statement generated by machine, not written by a human.

The coding conventions are aimed at maximum portability. For example:

• Only relatively short identifiers.
• No long character-string constants.
• Only #ifdef, #else, #endif, #define, and #undef preprocessor directives.
• Any code that uses ANSI features is enclosed in #ifdef __STDC__ ... #endif.
• No gmake-specific constructs in the makefile.

Here are some sample builds from version 1.00:

 Platform                         Size  Target    Notes            
  Apple Mac OS X 1.0 gcc:          48K   posix    (AKA Rhapsody 5.5)
  AT&T 3B2/300 SVR2 cc:            52K   sysv     (4)
  AT&T 6300 PLUS cc:               61K   sysv     (6)
  AT&T 7300 UNIX PC cc:            43K   sysv
  AT&T 7300 UNIX PC gcc:           58K   sysv     (25K with shared lib)
  BSDI 4.0.1 gcc:                  34K   posix
  DEC 5000 MIPS Ultrix 4.3 cc:    104K   posix
  DEC Alpha Digital UNIX 3.2 cc:   98K   bsd      (AKA OSF/1) (1)
  DEC Alpha Tru64 UNIX 4.0e cc:    82K   bsd      (1)
  DEC PDP-11 2.11BSD cc:           40K   bsd211   (7)
  DEC PDP-11 Ultrix 3.0 cc:        40K   bsd211   (9)
  DEC VAX 4.3BSD cc:               46K   bsd
  DEC VAX Ultrix 3.0 cc:           43K   bsd
  DG/UX 5.4R4.11 gcc:              51K   posix
  DYNIX/ptx 4.4.2 cc:              43K   posix
  FreeBSD 3.3 gcc:                 34K   posix
  GNU/Linux RH 5.2 gcc:            35K   posix    (RH = Red Hat)
  GNU/Linux SW 3.5 gcc:            34K   posix    (SW = Slackware)
  HP-UX 5.21 cc:                   55K   sysv     (2)
  HP-UX 6.5 cc:                    40K   sysv     (5)
  HP-UX 7.05 cc:                   50K   posix
  HP-UX 8.00 gcc:                  33K   posix
  HP-UX 9.05 cc:                   57K   posix
  HP-UX 10.01 cc:                  57K   posix
  HP-UX 10.20 cc:                  61K   posix
  IBM AIX 2.2.1 RT PC IBM cc:      62K   sysv
  IBM AIX 3.2 IBM cc:              62K   posix
  IBM AIX 4.1.3 IBM cc:            67K   posix
  Intergraph Clipper acc:          80K   sysv     (8)
  Motorola 68K SV/68 R3.6 cc:      58K   sysv     (4)
  Motorola 88K SV/88 R4.3 cc:      45K   posix
  NetBSD 1.4.1 gcc:                41K   posix
  NeXTSTEP m68k 3.1 gcc:           77K   bsd      (3)
  OPENSTEP m68k 4.2 gcc:           77K   bsd      (3)
  OpenBSD 2.5 gcc:                 47K   posix
  QNX 4.25 cc:                     33K   posix
  Red Hat 9 i386 gcc:              47K   posix    KFLAGS=-DERRNO_H
  Red Hat Linux RHEL5 x86_64       47K   posix    KFLAGS=-DERRNO_H
  SCO XENIX 2.3.4 cc:              41K   sysv     (4)
  SCO UNIX 3.2v4.2 cc:             73K   posix
  SCO UNIX 3.2v4.2 gcc:            61K   posix
  SCO ODT 3.0 cc:                  97K   posix
  SCO OSR5.0.5 gcc:                42K   posix
  SCO Unixware 2.1.3 cc:           38K   posix
  SGI IRIX 5.3 cc:                 86K   posix
  SGI IRIX 6.5.4 cc:               91K   posix
  SINIX 5.42 MIPS cc:              57K   posix
  Solaris 2.4 cc:                  50K   posix
  Solaris 7 cc:                    52K   posix
  Solaris 9 cc:                    52K   posix
  SunOS 4.1.3 cc:                  57K   posix
  SunOS 4.1.3 gcc:                 64K   posix                                     

Notes:

1. "make posix" builds without complaint on OSF/1 (Digital UNIX (Tru64)) but it doesn't work -- i/o hangs or program dumps core. "make bsd" works fine.

2. POSIX APIs not available in this antique OS (circa 1983). Also due to limited terminal input buffering capacity, streaming must be disabled and relatively short packets must be used when receiving: "gkermit -Se 250 -r". However, it can use streaming when sending.

3. POSIX APIs not available. Include KFLAGS=-DSIG_V if you get a lot of warnings about signal().

4. On System V R3 and earlier, EWOULDBLOCK is not defined, so we use EGAIN instead. No special build procedures needed.

5. Built with 'make -i "KFLAGS=-DDEFRP=512 -DUSE_GETCHAR" sysv'. It can be built without -DUSE_GETCHAR but doesn't work.

6. Use 'make "CC=cc -Ml "KFLAGS=-DUSE_GETCHAR"sysv'. It builds but doesn't work, reason unknown, but probably because it was never designed to be accessed remotely in the first place.

7. This is a 16-bit architecture. A special makefile target is needed because its make program does not expand the $(CC) value when invoking second-level makes. Packet and buffer sizes are reduced to keep static data within limits. Overlays are not needed.

8. Use 'make "CC=acc" sysv'.

9. Identifiers must be unique within the first 7 characters. Unfortunately, there is a conflict in gproto.w between streamon() and streamok. Build with 'make bsd211 "KFLAGS=-Dstreamon=strmon -DULONG=long -DSMALL"'. This was on a PDP-11/23+ without I&D space. -DSMALL might not be necessary with I&D space. When using, disable streaming and use shorter-than-usual packets.

13. INSTALLING G-KERMIT

DO NOT give SETUID or SETGID privilege to G-Kermit. G-Kermit is not a dialout program. It does not access serial devices or UUCP lockfiles, and it does not do real/effective ID switching. If you give it SETUID or SETGID privilege, this will open restricted files and directories to users who otherwise do not have access, and incoming files will be created with the wrong owner and/or group.

The executable should be called "gkermit" and not "kermit", since "kermit" is the binary name for C-Kermit, and the two are likely to be installed side by side on the same computer; even when they are not, consistent naming is better for support and sanity purposes. There is also a short man page:

gkermit.nr

You can view it with:

nroff -man gkermit.nr | more

Rename and store it appropriately so users can access it with 'man gkermit'. In addition, the README should be made available in a public documentation directory as:

gkermit.txt

The makefile includes a sample 'install' target that does all this. Please read it before use to be sure the appropriate directories and permissions are indicated. There is also an 'uninstall' target to undo an installation. Obviously you need write access to the relevant directories before you can install or uninstall G-Kermit.

14. DESIGN AND IMPLEMENTATION NOTES

• File timestamps. The methods for dealing with internal time formats are notoriously unportable and also a moving target, especially now with the 32-bit internal time format rollover looming in 2038 and the time_t data type changing out from under us. Furthermore, by excluding any date-handling code, G-Kermit is automatically Y2K, 2038, and Y10K "compliant".
• Internal wildcard expansion, recursive directory traversal, etc. Even after more than 30 years (no, make that 40), there is still no standard and portable service in Unix for this.
• Server mode, because it would require internal wildcard expansion.
• Hardware flow control, millisecond sleeps, nondestructive input buffer peeking, threads, select(), file permissions, etc etc.

Other features are omitted to keep the program small and simple, and to avoid creeping featurism:

• Sliding windows. This technique is more complicated than streaming but not as fast, and furthermore would increase the program size by a factor of 5 or 10 due to buffering requirements.
• An interactive command parser and scripting language (because users always want more and more commands and features).
• Character set conversion (because users always want more and more character sets). Adding character set support would increase the program size by a factor of 2 to 4, depending on the selection of sets.
• Making connections (because this requires huge amounts of tricky and unstable high-maintenance platform- and device-specific code for serial ports, modems, modem signals, network stacks and protocols, etc).
• Security. Not needed since G-Kermit does not make connections. When G-Kermit is on the far end of a secure connection (Telnet, SSH, Rlogin), the security is handled by the connecting client and the Telnet, SSH, or Rlogin server.

All of the above can be found in C-Kermit, which is therefore bigger and more complicated, with more platform-specific code and #ifdef spaghetti. C-Kermit requires constant updates and patches to keep pace with changes in the underlying platforms, networking and security methods, and demands from its users for more features.

The goal for G-Kermit, on the other hand, is simplicity and stability, so we don't need thousands of #ifdefs like we have in C-Kermit, and we don't need to tweak the code every time a new release of each Unix variety comes out. G-Kermit is meant to be PORTABLE and LONG-LASTING so the stress is on a MINIMUM of platform dependencies.

If you make changes, please try to avoid adding anything platform-dependent or in any other way destabilizing. Bear in mind that the result of your changes should still build and run successfully on at least all the platforms where G-Kermit was built originally. In any case, you are encouraged to send any changes back to the Kermit Project to be considered for addition to the master G-Kermit distribution.

15. FURTHER INFORMATION

16. DOWNLOAD

 Filename                           Description
  gku201.tar.gz                      G-Kermit 2.01 source tar archive, gzipped (63K)
  gku201.tar                         G-Kermit 2.01 source tar archive, not compressed (211K)
  gku201.zip                         G-Kermit 2.01 source ZIP archive (71K)
  File list                          Individual source and doc files (text)

 Filename                           Description
  gku200.tar.gz                      G-Kermit source tar archive, gzipped (62K)
  gku200.tar                         G-Kermit source tar archive, not compressed (215K)
  gku200.zip                         G-Kermit source ZIP archive (71K)
  File list                          Individual source and doc files (text)

Prebuilt binaries for G-Kermit 1.00

 Filename                           Description
  gku100.alpha-osf1-1.3              DEC Alpha with OSF/1 1.3
  gku100.alpha-du-3.2                DEC Alpha with Digital UNIX 3.2
  gku100.alpha-du-3.2c               DEC Alpha with Digital UNIX 3.2C
  gku100.alpha-du-3.2d               DEC Alpha with Digital UNIX 3.2D
  gku100.alpha-du-3.2g               DEC Alpha with Digital UNIX 3.2G
  gku100.alpha-du-4.0b               DEC Alpha with Digital UNIX 4.0B
  gku100.alpha-du-4.0c               DEC Alpha with Digital UNIX 4.0C
  gku100.alpha-du-4.0d               DEC Alpha with Digital UNIX 4.0D
  gku100.alpha-tru64-4.0e            DEC Alpha with Tru64 UNIX 4.0E
  gku100.alpha-tru64-4.0f            DEC Alpha with Tru64 UNIX 4.0F
  gku100.alpha-tru64-5.0a            DEC Alpha with Tru64 UNIX 5.0A
  gku100.alpha-tru64-5.1             DEC Alpha with Tru64 UNIX 5.1
  gku100.alpha-tru64-5.1a            DEC Alpha with Tru64 UNIX 5.1A
  gku100.alpha-freebsd-3.4           DEC Alpha with FreeBSD 3.4
  gku100.alpha-freebsd-4.4           DEC Alpha with FreeBSD 4.4
  gku100.alpha-freebsd-4.5           DEC Alpha with FreeBSD 4.5
  gku100.alpha-freebsd-4.6           DEC Alpha with FreeBSD 4.6
  gku100.alpha-freebsd-4.7           DEC Alpha with FreeBSD 4.7
  gku100.alpha-freebsd-6.0           DEC (HP) Alpha with FreeBSD 6.0
  gku100.alpha-linux-db2.2           DEC Alpha with Linux Debian 2.2
  gku100.alpha-linux-db3.0           DEC Alpha with Linux Debian 3.0
  gku100.alpha-linux-rh5.2           DEC Alpha with Linux Red Hat 5.2
  gku100.alpha-linux-rh6.1           DEC Alpha with Linux Red Hat 6.1
  gku100.alpha-linux-rh6.2           DEC Alpha with Linux Red Hat 6.2
  gku100.alpha-linux-rh7.1           DEC Alpha with Linux Red Hat 7.1
  gku100.alpha-linux-su6.1           DEC Alpha with Linux SuSE 6.1
  gku100.alpha-linux-su6.3           DEC Alpha with Linux SuSE 6.3
  gku100.alpha-linux-su6.4           DEC Alpha with Linux SuSE 6.4
  gku100.alpha-linux-su7.1           DEC Alpha with Linux SuSE 7.1
  gku100.alpha-netbsd-1.4            DEC Alpha with NetBSD 1.4
  gku100.alpha-netbsd-1.5.1          DEC Alpha with NetBSD 1.5.1
  gku100.alpha-netbsd-1.5.2          DEC Alpha with NetBSD 1.5.2
  gku100.alpha-netbsd-1.6            DEC Alpha with NetBSD 1.6
  gku100.amd64-freebsd-6.1           AMD_64 with FreeBSD 6.1
  gku100.armle-qnx-6.21              ARM platforms (Little Endian) QNX 6.21B
  gku100.armv41-linux-ipaq-db2.1     Compaq iPAQ H3650 Debian 2.1
  gku100.armv41-linux-shark-db2.1    Compaq SA-110 Shark Palmtop
  gku100.armv41-linux-zaurus-sl550   Sharp Zaurus SL5500 Palmtop
  gku100.att3b2-sysv-3.1             AT&T 3B2/200 with System V R3.1
  gku100.att7300-sysv-3.51           AT&T 7300 UNIX PC (3B1) with System V R3.51
  gku100.clipper-clix-3.1            Intergraph InterPro 2020 with CLIX 3.1V7.6.27
  gku100.cray_ymp-unicos-9.0         Cray Y-MP EL with UNICOS 9.0.2.2
  gku100.hp9000s300-netbsd-1.3.1     HP 9000 Model 300 with NetBSD 1.3.1
  gku100.hp9000s500-hpux-5.21        HP 9000 Model 550 with HP-UX 5.21
  gku100.hp9000s300-hpux-6.5         HP 9000 Model 3xx with HP-UX 6.5
  gku100.hp9000s300-hpux-7.05        HP 9000 Model 3xx with HP-UX 7.05
  gku100.hp9000s300-hpux-8.00        HP 9000 Model 3xx with HP-UX 8.00
  gku100.hp9000s400-hpux-8.00        HP 9000 Model 4xx with HP-UX 8.00
  gku100.hp9000s300-hpux-9.03        HP 9000 Model 3xx with HP-UX 9.03
  gku100.hp9000s700-hpux-9.05        HP 9000 Model 7xx with HP-UX 9.05
  gku100.hp9000s700-hpux-9.07        HP 9000 Model 7xx with HP-UX 9.07
  gku100.hp9000s300-hpux-9.10        HP 9000 Model 3xx with HP-UX 9.10
  gku100.hp9000s700-hpux-10.01       HP 9000 Model 7xx with HP-UX 10.01
  gku100.hp9000s700-hpux-10.20       HP 9000 Model 7xx with HP-UX 10.20
  gku100.hp9000s800-hpux-10.20       HP 9000 Model 8xx with HP-UX 10.20
  gku100.hp9000s700-hpux-11.00       HP 9000 Model 7xx with HP-UX 11.00
  gku100.hp9000s800-hpux-11.00       HP 9000 Model 8xx with HP-UX 11.00
  gku100.hp9000s700-hpux-11.11       HP 9000 Model 7xx with HP-UX 11.11
  gku100.hp9000s800-hpux-11.11       HP 9000 Model 8xx with HP-UX 11.11
  gku100.hp9000s800-hpux-11i-v2      HP 9000 Model 8xx with HP-UX 11i v2
  gku100.i386-aix-1.2.1              PC (PS/2) with AIX 1.2.1
  gku100.i386-beos-4.5               PC with BeOS 4.5
  gku100.i386-bsdi-4.0.1             PC with BSDI/OS 4.0.1
  gku100.i386-bsdi-4.1               PC with BSDI/OS 4.1
  gku100.i386-bsdi-4.2               PC with BSDI/OS 4.2
  gku100.i386-bsdi-4.3               PC with BSDI/OS 4.3
  gku100.i386-coherent-4.2           PC with Mark Williams Coherent 4.2
  gku100.i386-dgux54420              PC with DG/UX 5.4R4.20
  gku100.i386-dynixptx-4.4.2         PC with Sequent DYNIX/ptx 4.4.2
  gku100.i386-freebsd-1.0            PC with FreeBSD 1.0
  gku100.i386-freebsd-2.2.7          PC with FreeBSD 2.2.7
  gku100.i386-freebsd-2.2.8          PC with FreeBSD 2.2.8
  gku100.i386-freebsd-3.1            PC with FreeBSD 3.1
  gku100.i386-freebsd-3.3            PC with FreeBSD 3.3
  gku100.i386-freebsd-3.4            PC with FreeBSD 3.4
  gku100.i386-freebsd-4.0            PC with FreeBSD 4.0
  gku100.i386-freebsd-4.2            PC with FreeBSD 4.2
  gku100.i386-freebsd-4.3            PC with FreeBSD 4.3
  gku100.i386-freebsd-4.4            PC with FreeBSD 4.4
  gku100.i386-freebsd-4.5            PC with FreeBSD 4.5
  gku100.i386-freebsd-4.6            PC with FreeBSD 4.6
  gku100.i386-freebsd-4.7            PC with FreeBSD 4.7
  gku100.i386-freebsd-4.8            PC with FreeBSD 4.8
  gku100.i386-freebsd-5.0            PC with FreeBSD 5.0
  gku100.i386-is5r3-4.1.1            PC with Interactive UNIX System V/386 R3.2 R4.1.1
  gku100.i386-linux-ca3.1            PC with Caldera GNU/Linux 3.1
  gku100.i386-linux-db2.1            PC with Debian GNU/Linux 2.1
  gku100.i386-linux-db2.2            PC with Debian GNU/Linux 2.2
  gku100.i386-linux-db3.0            PC with Debian GNU/Linux 3.0
  gku100.i386-linux-md9.0            PC with Mandrake GNU/Linux 9.0
  gku100.i386-linux-rh5.1            PC with Red Hat GNU/Linux 5.1
  gku100.i386-linux-rh5.2            PC with Red Hat GNU/Linux 5.2
  gku100.i386-linux-rh6.1            PC with Red Hat GNU/Linux 6.1
  gku100.i386-linux-rh6.2            PC with Red Hat GNU/Linux 6.2
  gku100.i386-linux-rh7.0            PC with Red Hat GNU/Linux 7.0
  gku100.i386-linux-rh7.1            PC with Red Hat GNU/Linux 7.1
  gku100.i386-linux-rh7.2            PC with Red Hat GNU/Linux 7.2
  gku100.i386-linux-rh8.0            PC with Red Hat GNU/Linux 8.0
  gku100.i386-linux-rh9              PC with Red Hat GNU/Linux 9
  gku100.i386-linux-ra2.1            PC with Red Hat Advanced Server 2.1
  gku100.i386-linux-su5.3            PC with SuSE GNU/Linux 5.3
  gku100.i386-linux-su6.1            PC with SuSE GNU/Linux 6.1
  gku100.i386-linux-su6.2            PC with SuSE GNU/Linux 6.2
  gku100.i386-linux-su6.3            PC with SuSE GNU/Linux 6.3
  gku100.i386-linux-su6.4            PC with SuSE GNU/Linux 6.4
  gku100.i386-linux-su7.0            PC with SuSE GNU/Linux 7.0
  gku100.i386-linux-su7.3            PC with SuSE GNU/Linux 7.3
  gku100.i386-linux-sw3.4            PC with Slackware GNU/Linux 3.4
  gku100.i386-linux-sw3.5            PC with Slackware GNU/Linux 3.5
  gku100.i386-linux-sw4.0            PC with Slackware GNU/Linux 4.0
  gku100.i386-linux-sw7.0            PC with Slackware GNU/Linux 7.0
  gku100.i386-linux-sw7.1            PC with Slackware GNU/Linux 7.1
  gku100.i386-linux-sw8.0            PC with Slackware GNU/Linux 8.0
  gku100.i386-linux-sw9.0            PC with Slackware GNU/Linux 9.0
  gku100.i386-linux-tu6.5            PC with TurboLinux 6.5
  gku100.i386-linux-tu7.0            PC with TurboLinux 7.0
  gku100.i386-minix-2.0.2            PC with Minix 2.0.2 (32-bit)
  gku100.i386-mpras-2.03             PC with NCR MP-RAS 2.03
  gku100.i386-mpras-3.02             PC with NCR MP-RAS 3.02
  gku100.i386-netbsd-1.4p            PC with NetBSD 1.4P (ELF)
  gku100.i386-netbsd-1.4.1           PC with NetBSD 1.4.1
  gku100.i386-netbsd-1.5.2           PC with NetBSD 1.5.2
  gku100.i386-netbsd-1.5.4           PC with NetBSD 1.5.4
  gku100.i386-netbsd-1.6             PC with NetBSD 1.6
  gku100.i386-openbsd-2.5            PC with OpenBSD 2.5
  gku100.i386-openbsd-2.9            PC with OpenBSD 2.9
  gku100.i386-openbsd-3.0            PC with OpenBSD 3.0
  gku100.i386-openbsd-3.1            PC with OpenBSD 3.1
  gku100.i386-openbsd-3.2            PC with OpenBSD 3.2
  gku100.i386-os2-3.0                PC with IBM OS/2 3.0 and EMX 0.9c
  gku100.i386-plan9                  PC with Plan 9 from Bell Labs
  gku100.i286-qnx-4.25               PC with QNX 4.x (16 bit)
  gku100.i386-qnx-4.25               PC with QNX 4.25 (32 bit)
  gku100.i386-qnxnto-2               PC with QNX Neutrino 2+
  gku100.i386-qnx-6.1                PC with QNX 6.1
  gku100.i386-qnx-6.21               PC with QNX 6.21B
  gku100.i386-scoxenix-2.3.4         PC with SCO XENIX 2.3.4
  gku100.i386-scounix-3.2v4.2        PC with SCO UNIX 3.2v4.2
  gku100.i386-scoodt-3.0             PC with SCO ODT 3.0
  gku100.i386-scoosr5-5.0.2          PC with SCO OSR5.0.2
  gku100.i386-scoosr5-5.0.4          PC with SCO OSR5.0.4
  gku100.i386-scoosr5-5.0.5          PC with SCO OSR5.0.5
  gku100.i386-scoosr5-5.0.6          PC with SCO OSR5.0.6
  gku100.i386-scoosr5-5.0.7          PC with SCO OSR5.0.7
  gku100.i386-scoosr6-6.0.0          PC with SCO OSR6.0.0
  gku100.i386-scoou8-8.0.0           PC with SCO Open Unix 8.0.0
  gku100.i386-scoou8-8.0.1           PC with SCO Open Unix 8.0.1
  gku100.i386-sinix-5.41             PC with Siemens Nixdorf SINIX-L 5.41
  gku100.i386-solaris-2.5.1          PC with Solaris 2.5.1
  gku100.i386-solaris-2.6            PC with Solaris 2.6
  gku100.i386-solaris-8              PC with Solaris 8
  gku100.i386-solaris-9              PC with Solaris 9
  gku100.i386-solaris-10             PC with Solaris 10
  gku100.i386-unixware-2.1.0         PC with UnixWare 2.1.0
  gku100.i386-unixware-2.1.3         PC with UnixWare 2.1.3
  gku100.i386-unixware-7.0.1         PC with UnixWare 7.0.1
  gku100.i386-unixware-7.1.0         PC with UnixWare 7.1.0
  gku100.i386-unixware-7.1.1         PC with UnixWare 7.1.1
  gku100.i386-unixware-7.1.3         PC with UnixWare 7.1.3
  gku100.ia64-hpux-11.22             IA64 (Itanium) with HP-UX 11.22i v2
  gku100.ia64-hpux-11.23             IA64 (Itanium) with HP-UX 11.23i v2
  gku100.ia64-linux-db3.0            IA64 (Itanium) with Debian Linux 3.0
  gku100.ia64-linux-rh7.1            IA64 (Itanium) with Red Hat Linux 7.1
  gku100.ia64-linux-rh7.2            IA64 (Itanium) with Red Hat Linux 7.2
  gku100.ia64-linux-su7.2            IA64 (Itanium) with SuSE Linux 7.2
  gku100.m68k-linux-db2.1            Motorola 680x0 with Linux Debian 2.1
  gku100.m68k-linux-db2.2            Motorola 680x0 with Linux Debian 2.2
  gku100.m68k-netbsd-1.4.2a          Motorola 680x0 with NetBSD 1.4.2-Alpha
  gku100.m68k-cpm68k-1.2             Motorola 68020 with CP/M-68K 1.2 (rename to gkermit.rel)
  gku100.m68k-sv68-r3.6              Motorola MVME 147 68K, System V/68 R3V6
  gku100.mvme68k-netbsd-1.5.2        Motorola MVME 147 or 167 m68k, NetBSD 1.5.2
  gku100.m68k-nextstep-3.1           NeXTstation with NeXTSTEP 3.1
  gku100.m68k-nextstep-3.3           NeXTstation with NeXTSTEP 3.3
  gku100.m68k-openstep-4.2           NeXTstation with OPENSTEP 4.2
  gku100.m68k-tandy6000-xenix-3.0    Tandy 16/6000 Microsoft XENIX 3.02.00
  gku100.m88k-dgux-5.4r3.10          Data General AViiON 88110 with DG/UX 5.4R3.10
  gku100.m88k-dgux-5.4r4.11          Data General AViiON 88110 with DG/UX 5.4R4.11
  gku100.m88k-sv88-r4.3              Motorola MVME 187 88K, System V R4 V4.3
  gku100.m88k-sv88-r4.4              Motorola MVME 187 88K, System V R4 V4.4
  gku100.mips-irix-5.3               SGI with IRIX 5.3 (MIPS-1)
  gku100.mips-irix-6.2               SGI with IRIX 6.2 (MIPS-2)
  gku100.mips-irix-6.3               SGI with IRIX 6.3 (MIPS-2)
  gku100.mips-irix-6.2-n32           SGI with IRIX 6.2 (MIPS-3)
  gku100.mips-irix-6.2-64            SGI with IRIX 6.2 (64-bit)
  gku100.mips-irix-6.5.2             SGI with IRIX 6.5.2
  gku100.mips-irix-6.5.4             SGI with IRIX 6.5.4
  gku100.mips-irix-6.5.6             SGI with IRIX 6.5.6
  gku100.mips-irix-6.5.10            SGI with IRIX 6.5.10
  gku100.mips-be-qnx-6.21            MIPS platforms (Big Endian) QNX 6.21B
  gku100.mips-le-qnx-6.21            MIPS platforms (Little Endian) QNX 6.21B
  gku100.mips-sinix-5.42             Siemens Nixdorf RM200 with SINIX 5.42
  gku100.mips-reliant-5.43           Siemens Nixdorf RM600 with Reliant UNIX 5.43
  gku100.mips-reliant-5.44           Siemens Nixdorf RM600 with Reliant UNIX 5.44
  gku100.mips-linux-db3.0            DECstation 5000 with Debian Linux 3.0
  gku100.mips-linux-gentoo-1.4.16    SGI Indy-200 with Gentoo Linux 1.4.16
  gku100.mips-netbsd-1.4.1           DECstation 5000 with NetBSD 1.4.1
  gku100.mips-ultrix-4.3             DECstation 5000 with Ultrix 4.3
  gku100.mips-ultrix-4.3a            DECstation 5000 with Ultrix 4.3A
  gku100.pdp11-bsd-2.11              DEC PDP-11/44(?) with 2.11BSD
  gku100.pdp11-ultrix11-3.0          DEC PDP-11/23+ with Ultrix-11 3.0 (no I&D)
  gku100.vax-bsd-4.2                 DEC VAX with 4.2BSD
  gku100.vax-bsd-4.3                 DEC VAX with 4.3BSD
  gku100.vax-ultrix-3.0              DEC VAX with Ultrix 3.0
  gku100.vax-ultrix-4.5              DEC VAX with Ultrix 4.5
  gku100.parisc-ftx-3.4              Stratus Continuum (PA-RISC), FTX 3.4
  gku100.ppc-linux-db2.2             Apple Power Mac with Linux Debian 2.2
  gku100.ppc-linux-yd2.3             Apple Power Mac with Linux Yellow Dog 2.3
  gku100.ppc-linuxppc-1999q2         Apple Power Mac with LinuxPPC 1999 Q2
  gku100.ppc-linuxppc-2000q4         Apple Power Mac with LinuxPPC 2000 Q4
  gku100.ppc-linux-su6.3             Apple Power Mac with Linux SuSE 6.3
  gku100.ppc-linux-su6.4             Apple Power Mac with Linux SuSE 6.4
  gku100.ppc-macosx-1.0              Apple Power Mac with Mac OS X 1.0 (Rhapsody 5.5)
  gku100.ppc-macosx-10.1.1           Apple Power Mac with Mac OS X 10.1.1
  gku100.ppc-darwin-1.3.3            Apple Power Mac with Apple Darwin 1.3.3
  gku100.ppc-darwin-5.3              Apple Power Mac with Apple Darwin 5.3
  gku100.ppc-macosx-10.2             Apple Power Mac with Mac OS X 10.2
  gku100.ppc-beos-4.5                BeBox, BeOS 4.5
  gku100.ppc-powermax-5.1            Concurrent PowerMAX OS 5.1
  gku100.ppc-qnx-6.21                PowerPC (Big Endian) QNX 6.21B
  gku100.rtpc-aix-2.2.1              IBM RT PC, AIX 2.2.1
  gku100.rtpc-aos-4.3                IBM RT PC, AOS 4.3BSD
  gku100.rs6000-aix-3.2.0            IBM Power Series with AIX 3.2.0
  gku100.rs6000-aix-3.2.5            IBM Power Series with AIX 3.2.5
  gku100.ppc-aix-4.1.3               IBM Power Series with AIX 4.1.3
  gku100.ppc-aix-4.1.5               IBM Power Series with AIX 4.1.5
  gku100.ppc-aix-4.2.1               IBM Power Series with AIX 4.2.1
  gku100.ppc-aix-4.3.2               IBM Power Series with AIX 4.3.2
  gku100.ppc-aix-4.3.3               IBM Power Series with AIX 4.3.3
  gku100.ppc-aix-5.1                 IBM Power Series with AIX 5.1
  gku100.pyramid-dcosx-1.1           Pyramid MIS-ES6/1024 SMP DC-OSx1.1-95c087.4
  gku100.s390-linux390               IBM System/390 with Linux/390
  gku100.s390-linux-su7.0            IBM System/390 with SuSE Linux 7.0
  gku100.sh4-qnx-6.21                SH4 platforms (Little Endian) QNX 6.21B
  gku100.sun3-sunos-4.1.1            Sun/3 with SunOS 4.1.1
  gku100.sparc-linux-db2.2           Sun Sparc with Linux Debian 2.2
  gku100.sparc-linux-rh6.1           Sun Sparc with Linux Red Hat 6.1
  gku100.sparc-linux-rh6.2           Sun Sparc with Linux Red Hat 6.2
  gku100.sparc-linux-su7.1           Sun Sparc with Linux SuSE Linux 7.1
  gku100.sparc-netbsd-1.4.1          Sun Sparc with NetBSD 1.4.1
  gku100.sparc-openbsd-2.3           Sun Sparc with OpenBSD 2.3
  gku100.sparc-sunos-4.1.1           Sun Sparc with SunOS 4.1.1
  gku100.sparc-sunos-4.1.3           Sun Sparc with SunOS 4.1.3
  gku100.sparc-solaris-1.0.1         Sun (Tadpole) SparcBook2 with Solaris 1.0.1
  gku100.sparc-solaris-2.4           Sun Sparc with Solaris 2.4
  gku100.sparc-solaris-2.5.1         Sun Sparc with Solaris 2.5.1
  gku100.sparc-solaris-2.6           Sun Sparc with Solaris 2.6
  gku100.sparc-solaris-7             Sun Sparc with Solaris 7
  gku100.sparc-solaris-8             Sun Sparc with Solaris 8
  gku100.sparc-solaris-9             Sun Sparc with Solaris 9
  gku100.sparc-solaris-10            Sun Sparc with Solaris 10
  gku100.x86_64-linux-rh3.0as        AMD Opteron x86 64-bit Red Hat Linux 3AS

17. BOOTSTRAPPING

THIS PROCEDURE ASSUMES THE TARGET COMPUTER HAS A UUDECODE PROGRAM AND AN UNCOMPRESS PROGRAM
(unfortunately by 2020 these utilities had largely disappeared from the scene).

G-Kermit is especially handy when your UNIX computer has no other file transfer method that you can use. In this case, it is often possible to "bootstrap" G-Kermit onto your computer because of its small size. Suppose Computer A is a UNIX computer on the Internet, and Computer B is the unconnected computer where you want to install G-Kermit. Download the binary for Computer B to Computer A from the Kermit website, then compress it on computer A, and then uuencode it, for example (the parts you type are underlined):

$ mv gku100.att7300-sysv-3.51 gkermit
$ compress gkermit
$ uuencode gkermit.Z gkermit.Z > gkermit.Z.uue

This gives a 35K text file having 573 lines. Now use a terminal emulator such as C-Kermit, Kermit 95, or MS-DOS Kermit to make a connection to Computer B, for example by modem or direct serial connection, log in, and give a "cat" command to copy incoming characters to a file; for example

C-Kermit> set line /dev/ttyS0
C-Kermit> set speed 57600
C-Kermit> set set flow-control none
C-Kermit> set carrier-watch off
C-Kermit> connect
login: youruserid
Password:       
$
$ cat > gkermit.Z.uue

Now "escape back" from the connection by typing Ctrl-Backslash (hold down the Ctrl key and press the Backslash (\) key); now you should have the "C-Kermit>" prompt again. At the C-Kermit prompt give a TRANSMIT command for the uuencoded file, e.g.:

C-Kermit> transmit gkermit.Z.uue

If you are using a non-Kermit terminal program, it probably won't have a TRANSMIT command, but it is likely have an "upload with ASCII protocol" choice in its protocols menu, so use that.

When the upload is finished, connect back to Computer B and type Ctrl-D (hold down the Ctrl key and press the D key) to close the new file and return to the shell prompt, and then:

$ uudecode gkermit.Z.uue
$ uncompress gkermit.Z
$ chmod +x gkermit

Now you have a file transfer program on computer B. Of course this bootstrapping method is error prone since "ASCII" is not an error-correcting protocol, so you might have to try several times, perhaps reducing your serial speed. But once gkermit is successfully installed on Computer B, you can use it to transfer files into and out of Computer B to/from any computer that has a Kermit program and that can make a connection to Computer B. You can also use gkermit to receive the larger C-Kermit, which then gives Computer B dialout and scripting capabilities.