Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!cs.utexas.edu!ut-emx!mjl
From: mjl@ut-emx.UUCP (Maurice LeBrun)
Newsgroups: comp.sys.amiga
Subject: Re: Binaries/sources
Message-ID: <11139@ut-emx.UUCP>
Date: 11 Mar 89 22:41:25 GMT
References: <333@sagpd1.UUCP> <12009@swan.ulowell.edu> <464@laic.UUCP>
Reply-To: mjl@emx.UUCP (Maurice LeBrun)
Distribution: usa
Organization: UTexas Computation Center, Austin, Texas
Lines: 27

In article <464@laic.UUCP> darin@nova.UUCP (Darin Johnson) writes:
>Unshar'ing and uudecoding on the UNIX side is fine.  If you're on a
>VMS machine, it can cause problems.  (I use the VMS machine because it
>has a 2400baud modem)  Even though I have uudecode and unshar on my
>VMS machine, the zoo file will not survive intact.  This is because
>a record format and record size are enforced on the zoo file just
>created from uudecode.  If you happen to use a version of kermit,
>xmodem, etc that exactly reverses these changes, then you are ok.
>However, the most popular terminal programs do not do this.

UUdecode writes out the file as record type STREAM_LF in VMS.  This is
Dec's version of a vanilla binary file.  Unfortunately, most file
transfer utilities (ftp binary, kermit, xmodem..) need it to be in 512
byte fixed record format.  The solution is to run the file through a
conversion routine, called 'bilf', that is included with zoo (which
*does* run on vms).  I do all my unshar'ing and uudecoding on the vax,
as it saves download time.  And with zoo there, I can check on the
archive's integrity as well.

BTW, I think I got zoo & bilf via anonymous ftp from j.cc.purdue.edu
from the /comp.sources.unix (?) archive.

Maurice LeBrun		      |   "So then I says to Borg, `You know,
Institute for Fusion Studies  |  as long as we're under siege, one of us
University of Texas at Austin |    oughta moon these Saxon dogs.'"
Internet:                     |
  mjl@fusion.ph.utexas.edu    |                   (Far Side)