<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9"> <TITLE> The MacTerminal MINI-HOWTO: Client-server connection with kermit.</TITLE> <LINK HREF="Mac-Terminal-4.html" REL=next> <LINK HREF="Mac-Terminal-2.html" REL=previous> <LINK HREF="Mac-Terminal.html#toc3" REL=contents> </HEAD> <BODY> <A HREF="Mac-Terminal-4.html">Next</A> <A HREF="Mac-Terminal-2.html">Previous</A> <A HREF="Mac-Terminal.html#toc3">Contents</A> <HR> <H2><A NAME="s3">3. Client-server connection with <CODE>kermit</CODE>.</A></H2> <P>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. <P>In brief, you start <CODE>kermit</CODE> 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 <CODE>kermit</CODE> can take advantage of Linux's superior scripting abilities, so it seems logical (to me at least) to designate the Linux-side <CODE>kermit</CODE> as the server, because this is the more readily automated task. <P>You should ensure that <CODE>kermit</CODE> is installed correctly on both the Mac and the Linux PC. Follow the instructions in the respective kermit distributions. On the Linux machine type <CODE>kermit</CODE> at the shell prompt to start it. You may need root permissions in order to set the port and baud rate. <P><CODE>kermit</CODE>, 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 <CODE>kermit</CODE> and serial lines are concerned. However, <CODE>kermit</CODE> 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 <CODE>kermit</CODE> serial connections than your TCP/IP connections, because Mac <CODE>kermit</CODE> will rudely hose a serial port that is already in use. <P>With that in mind, your <CODE>.kermrc</CODE> file would contain something like this: <PRE> 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 binary </PRE> Then, in your <CODE>~/.kermrc</CODE> file, you would have a line like <PRE> take /usr/local/bin/ckermit.local.ini </PRE> On 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, <CODE>kermit</CODE> 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. <P>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 <CODE>kermit</CODE> docs for details of server mode. <P> <H2><A NAME="ss3.1">3.1 Macintosh resources.</A> </H2> <P>This is one of the very few <CODE>kermit</CODE> applications where setting a <CODE>text</CODE> file type for transfers is useful. This is because Macintosh files have two parts: the <B>data fork</B> and the <B>resource fork</B>. 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. <P>When transferring binary files between the two systems, you should use the Macintosh <CODE>.hqx</CODE> 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. <P>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 <CODE>mac.archive.umich.edu</CODE>. 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 <CODE>TEXT</CODE>, 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 <CODE>EMAC</CODE>, for example. If in doubt what the creator code of your text editor or word processor is, use <CODE>ttxt</CODE>, which is the creator code for TeachText (which is the Mac equivalent of <CODE>EDLIN.EXE</CODE>.) Then your real word processor or text editor can translate the file from TeachText to its native type. <P>There are many other neato things which TeachText can do, so it's worthwhile to keep it permanently on your Mac. The book <EM>Voodoo Mac,</EM> by Kay Yarborough Nelson, is a good source of tried-and-true Macintosh tricks that use ResEdit, TeachText, the Finder, and other overlooked programs. <P> <HR> <A HREF="Mac-Terminal-4.html">Next</A> <A HREF="Mac-Terminal-2.html">Previous</A> <A HREF="Mac-Terminal.html#toc3">Contents</A> </BODY> </HTML>