Path: utzoo!attcan!uunet!lll-winken!ames!oliveb!pyramid!athertn!paul
From: paul@athertn.Atherton.COM (Paul Sander)
Newsgroups: comp.sys.apple
Subject: Re:  Kermit 3.85
Keywords: one problem solved
Message-ID: <308@athertn.Atherton.COM>
Date: 28 Feb 89 19:41:02 GMT
Organization: Atherton Technology, Sunnyvale, CA
Lines: 95


I downloaded Kermit 3.85 for the first time last night, and I ran across
the same problem Scott Hutinger had last week.  The problem is this:  after
using the scripts posted by Lazlo Nibble to convert Unix newlines to Apple
CRs, I downloaded the APP385.1 and APP385.2 using my favorite communication
program ("favorite," because I don't have Kermit yet).  After backing up
the disk, I followed the installation instructions, entering
"EXEC APP385.1,R25".  The disk sat and spun for a while, eventually stopping
with an END OF DATA message.

The rest of this posting discusses why this happened, and how I repaired it.
If you have been having problems with Kermit which are not described above,
this article is not for you.

The problem arises from incompatible ASCII formats, among other things.  Yes, 
ASCII is a standard, but so is RS-232, so the word "standard," like the word 
"should," is undefined in this industry. :-) :-) :-)

Unix stores characters in 7-bit ASCII.  On machines that store characters in
8-bit bytes (do I dare say most?) the character is usually stored in the
least significant bits of the byte, and set the most significant bit to a
zero.  Furthermore, lines of text are separated by an LF (linefeed) character.

Apple's DOS 3.3, on the other hand, stores characters in the least significant
7 bits of a byte, and then sets the most significant bit to a ONE, and it
separates lines of text with a CR (carriage return) character.

Using the shell scripts posted by Lazlo Nibble or Sean Kamath, the LF -> CR
translation can be done painlessly.

Transferring the file can be painful.  In my case (using ASCII Express
XMODEM protocol transfers), the files came into my machine with the most
significant bits of the ASCII characters set to zero.

When I EXEC'ed APP385.1, DOS didn't recognize the text for what it was, and
read all the way to the end of the file and then gave an error, without
performing the installation.

Following is a quick Applesoft hack that I used to copy the files while
setting the MSBs correctly:

5 INPUT "ENTER INPUT DRIVE: ";D1
10 INPUT "ENTER INPUT FILE: ";F1$
15 INPUT "ENTER OUTPUT DRIVE: ";D2
20 INPUT "ENTER OUTPUT FILE: ";F2$
30 D$ = CHR$(4)
40 ONERR GOTO 1000
50 PRINT D$;"OPEN ";F1$;",D";D1
60 PRINT D$;"OPEN ";F2$;",D";D2
70 REM
75 S$ = ""
80 PRINT D$;"READ ";F1$
90 GET C$
91 IF C$ = CHR$(13) THEN 100
92 S$ = S$ + C$
93 GOTO 90
100 PRINT
105 PRINT D$;"WRITE ";F2$
110 PRINT S$
120 GOTO 70
1000 REM
1010 E = PEEK(222)
1020 IF E = 5 THEN 1040
1030 PRINT "ERROR ";E;" HAS OCCURED"
1040 REM
1050 PRINT D$;"CLOSE ";F1$
1060 PRINT D$;"CLOSE ";F2$
1070 END

This program is a simple sequential file copy, but it relies on a side-effect
of DOS' I/O:  That it sets the MSB of any character it writes to a file.  By
simply reading and writing the file, it becomes EXEC'able!

Note that this does not work when using COPY or COPYA, as they copy disks on
a track-by-track basis, and it doesn't work with FID, because it copies on
a sector-by-sector basis.  This works because it copies on a character-by-
character basis.

To get Kermit to install, download its files, then copy the files to a new
disk using this program.  IMPORTANT:  Give the copied files names different
from APP385.1 and APP385.2, as this will confuse DOS.  After the files have
been copied, rename the copies back to APP385.1 and APP385.2 and 
EXEC APP385.1,R25 .

Note that this is a quick hack to solve a problem.  There is no error checking
to speak of, and no guards against pilot error.

Good luck!

Paul
paul@Atherton.COM
-- 
Paul Sander        (408) 734-9822       | Do YOU get nervous when a
paul@Atherton.COM                       | sys{op,adm,prg,engr} says
{decwrl,sun,hplabs!hpda}!athertn!paul   | "oops..." ?