This is the most transient of all the configurations described here. It requires the least amount of system configuration, although in operation, it is the more difficult to use of the systems described here.
In brief, you start
kermit on both the Linux machine and the
Mac, and place one of them in server mode. It doesn't matter which
machine is the client ant which is the server, because this is a
peer-to-peer connection. However, the Linux
kermit can take
advantage of Linux's superior scripting abilities, so it seems logical
(to me at least) to designate the Linux-side
kermit as the
server, because this is the more readily automated task.
You should ensure that
kermit is installed correctly on both
the Mac and the Linux PC. Follow the instructions in the respective
kermit distributions. On the Linux machine type
the shell prompt to start it. You may need root permissions in order
to set the port and baud rate.
kermit, the recent POSIX versions for Unices, supports baud
rates up to 115 Kbps. The more recent Macintosh versions support
serial port speeds up to 57.6 Kbps. This should be more than
sufficient for any dumb tty-type application, but if you need a
higher-speed connection, you're s.o.l, as far as
serial lines are concerned. However,
facilities for communication over a TCP/IP link, but I haven't been
able to test it. See the alternative in the following sections. Just
remember, especially on the Mac side, to use a different port for
kermit serial connections than your TCP/IP connections,
kermit will rudely hose a serial port that is
already in use.
With that in mind, your
.kermrc file would contain something
echo Executing site initialization file /usr/local/bin/ckermit.local.ini.... set prompt Chanel3 > set line /dev/ttyS0 set baud 38400 set send packet-length 2000 set receive packet-length 2000 set block 3 set file type binaryThen, in your
~/.kermrc file, you would have a line like
take /usr/local/bin/ckermit.local.iniOn the Macintosh side, set the same communication parameters for bps, stop bits, parity, and word length. Some older versions of Mac Kermit do not support 2k packets, so you might need to set a smaller packet size. Howerver,
kermit sets the communication packet length
based on the receive packet-length setting, so you need to set a shorter
packet size on the Linux end, too.
To actually communicate over the link, you need to enter server mode
on either the Mac or Linux side. It doesn't matter which. See the
kermit docs for details of server mode.
This is one of the very few
kermit applications where setting
text file type for transfers is useful. This is because
Macintosh files have two parts: the data fork and the
resource fork. The data fork corresponds to what we in the
Linux world think of as a file: it's the actual data. The resource
fork contains bitmaps for the icons, keymaps, font specifications, and
the like. If you transfer a file from Linux to the Mac, the file
won't be recognized as a text file by the Mac, if you use binary mode.
When transferring binary files between the two systems, you should use
.hqx BinHex format, which is a 7-bit encoding
of an 8-bit data file. Mac utilities like BinHexer or StuffIt will
covert the file to its binary form.
If you have a text file which inadvertently ends up as a data-only
file on the Mac, it's likely that it won't even appear in an Open
dialog list box. What you need to do is open the file with ResEdit,
which is available from
mac.archive.umich.edu. ResEdit will
tell you that the file you're opening has no resource fork and then
asks if you would like to add one. You should answer "Yes" to this
question. You can then edit the file's Type and Creator by selecting
the Open Special option of the File menu. All Macintosh text files
TEXT, so replace the question marks in the Text box
with that. The Creator code depends on your text editor or word
processor. Each one is unique, incidentally, and is how the Mac
identifies different apps. The Creator code for GNU Emacs on the Mac
EMAC, for example. If in doubt what the creator code of
your text editor or word processor is, use
ttxt, which is the
creator code for TeachText (which is the Mac equivalent of
EDLIN.EXE.) Then your real word processor or text editor can
translate the file from TeachText to its native type.
There are many other neato things which TeachText can do, so it's worthwhile to keep it permanently on your Mac. The book Voodoo Mac, by Kay Yarborough Nelson, is a good source of tried-and-true Macintosh tricks that use ResEdit, TeachText, the Finder, and other overlooked programs.