Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!vsi1!altnet!uunet!munnari!munnari.oz!kre
From: kre@munnari.oz (Robert Elz)
Newsgroups: comp.dcom.modems
Subject: Re: need help with xenix Kermit to PC procomm
Message-ID: <2320@munnari.oz>
Date: 27 Aug 88 05:32:27 GMT
References: <20302@neabbs.UUCP> <11744@oberon.USC.EDU> <6729@bigtex.uucp> <11996@steinmetz.ge.com>
Sender: news@munnari.oz
Lines: 30

In article <11996@steinmetz.ge.com>, davidsen@steinmetz.ge.com
(William E. Davidsen Jr) writes:
> I'm not sure what you're suggesting here. Why would I want to put a
> binary file into ASCII when I can move it in binary with kermit?

If you have an 8 bit data path, you don't.  If you have a 7 bit data path
(kermit with partiy defined as something other than none) then you win
y keeping the data as 7 bit, rather than 8 (kermit's 8 bit quoting isn't
optimized for transferring arbitrary binary files).

> And why not use atob which comes with the compress program (in most archives)?
> It produces output files about 10% smaller than uuencode.

I said "encode" not "uuencode".  The sole advantage to uuencode is that
it is universal, everyone has it.  Apart from that it's trash.

"Btoa" inserts newlines at regular intervals in its output, so the result
looks like a regular text file, which can be mailed, edited, or whatever
by anyone's standard tools.  Btoa also adds a checksum so corrupted files
can be detected (which is extremely useful for files sent through mailers).

"Encode" produces a 7 bit only file which is one huge line (actually, not
even that, as there's no terminating \n) with even smaller expansion than
btoa does .. if all you want is to get 7 bits for kermit with parity, or
uucp 'f' protocol, or some other reliable 7 bit only, or 7 bit preferred,
transport mechanism, encode does a better job than atob.

Since encode comes with the news software, it also exists in most archives.

kre