Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!njin!princeton!udel!wuarchive!emory!ogicse!cvedc!mcspdx!adphdw20!dtb
From: dtb@adpplz.UUCP (Tom Beach)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: Problem retrieving archive programs via FTP
Summary: It may not be kermit.
Keywords: archive FTP Kermit
Message-ID: <460@adphdw20.UUCP>
Date: 14 Feb 91 19:44:11 GMT
References: <1991Feb13.042158.25755@csuvax1.csu.murdoch.edu.au> <1991Feb13.152910.16132@linus.mitre.org>
Distribution: usa
Organization: ADP Dealer Services R&D, Portland, OR
Lines: 21

In article <1991Feb13.152910.16132@linus.mitre.org>, dhf@linus.mitre.org (David H. Friedman) writes:
> 
>    I was doing essentially the same thing, ftp'ing files from wustl and
> kermit'ing to a PC for copy to a diskette. In my case, .ZIP files wouldn't
> unZIP properly on the PC. I finally compared hex dumps on the PC and on my
> UNIX box, and found that the Kermit-to-Kermit transfer was introducing extra
> characters - it looked like every 0Ah was being changed to 0Dh 0Ah, i.e.,
> every CR was being changed to LF-CR even though the transfer mode was
> supposedly BINARY! I couldn't find which Kermit parameter, if any, enabled
... stuff deleted

My PC is connected to our local UNIX server over PC/NFS ethernet link.
This setup allows me to access files on the UNIX system either by doing
a remote login to the workstation or accessing directly through NFS
from the PC. I have found that when I UUDECODE the files with the PC
they will not unzoo because of extraneous LFs evidently either appended
by my UUDECODE or DOS itself. If I run UUDECODE from UNIX, switch back
to the PC to run looz212 it works as expected. The point is it may
not be kermit that's introducing the extraneous linefeeds.

Tom:  dtb@adpplz.uucp