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
kermit at 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
kermit and serial lines are concerned. However,
kermit provides 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, because Mac
kermit will rudely hose a serial port that is already in use.
With that in mind, your
.kermrc file would contain something like this:
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
~/.kermrcfile, 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,
kermitsets 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 a
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 the Macintosh
.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 are type
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 is
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.