Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!yale!umich!sharkey!dexter!jsr
From: jsr@dexter.mi.org (Jay S. Rouman)
Newsgroups: comp.sys.next
Subject: Re: Another KErmit problem!!
Message-ID: <1991May27.135314.12950@dexter.mi.org>
Date: 27 May 91 13:53:14 GMT
References: <15153@ccncsu.ColoState.EDU> <1991May27.051141.23286@casbah.acns.nwu.edu>
Organization: Private System, Mt. Pleasant, MI
Lines: 23

In article <1991May27.051141.23286@casbah.acns.nwu.edu> jweiss@casbah.acns.nwu.edu (Jerry Weiss) writes:
>In article <15153@ccncsu.ColoState.EDU> nates@sporobolus.UUCP (Nate Sammons) writes:
>>	but, now, kermit is running, (Alpha 23, I believe.)
>>But, when I download something, I can sometimes uudecode it,
>>but not always, and even when I do, it will not uncompress
>>or untar (tar -xf filename)...
>>..........
>
>I have seen this problem as well.  I am downloading files to a machine with
>an Internet connection, then kermiting the results to our Next.  I noticed 
>however than if I uncompress before I kermit, I am more successful.

It sounds like the sending Kermit is not set to binary.  Since the
sending end controls the attribute packets, it's easy to set your
receiving Kermit to binary and assume everything will be ok.  Not so.

Use SET FILE TYPE BINARY on the remote end before invoking a SEND or
SERVER command.  Alternatively, "kermit -i -x" will invoke Kermit as a
binary-sending server.  The default TEXT mode will happily garbage
compressed files.
-- 
Jay S. Rouman       Voice: 517/773-7887 | Distrust education.  Two of
              E-mail: jsr@dexter.mi.org | the three R's are misspelled.