Path: utzoo!attcan!uunet!snorkelwacker!husc6!wjh12!djb
From: djb@wjh12.harvard.edu (David J. Birnbaum)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: which archiver/compresser and encoder/decoder to use?
Message-ID: <448@wjh12.harvard.edu>
Date: 22 Feb 90 13:44:56 GMT
References: <36517@iuvax.cs.indiana.edu> <7806@yunexus.UUCP> <36569@iuvax.cs.indiana.edu> <100118@looking.on.ca>
Reply-To: djb@wjh12.UUCP (David J. Birnbaum)
Organization: Harvard University, Cambridge MA
Lines: 54

In article <100118@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes:

>Even if the chosen encoder is not to be ABE, it should at least be something
>a bit fancier than xxencode, with some support for multi-part encodings without
>requring unpacking or hand editing.

Having been bitten by the ASCII<-->EBCDIC problem many times, I recently
surveyed 8-bit/7-bit encoding programs that could survive transmission
between Internet and Bitnet sites.  These included ABE/DABE, ASCIFY,
UTIL3, and XXENCODE/XXDECODE.  All produced 7-bit files that avoided the
problematic characters used by UUENCODE.

ABE was the only program with a built-in ability to generate multipart
files; the other programs produced single large files that had to be
split by hand (using CHOP or a similar utility) and then recombined by
hand (using CAT or a similar utility - but not MS-DOS COPY).  Not only
does ABE split the file pieces for you, but, according to Brad's descrip-
tion, DABE will also combine them in the correct order, obviating any
need for cat.

The latter feature, alas, is not supported in the MS-DOS version of DABE,
perhaps because command.com isn't as friendly about sorting filenames as
other operating systems.  Be that as it may, DABE on an MS-DOS system
will require help in getting the pieces in the correct order.  I usually
do all archiving and 7-bit encoding on my PC, so that this missing feature
in the MS-DOS implementation of DABE is significant.  I should add that
the other decoders (XXDECODE, ASCIFY, and UTIL3) do not provide a facility
for combining pieces of files at all.  DABE at least provides it
on some systems.  Adding this feature to the MS-DOS implementation of
DABE would increase its appeal.

By the way, the xxencode/xxdecode executables that I received from
Simtel20 always seem to combine to produce a read-only file.  That is,
the xxencoded file has normal attributes, but decoding it restores the
original file with the read-only attribute set.  An xxencoded file that
I received from another site could be xxdecoded without this problem.
I understand there is supposed to be a '-r' switch that will force a
read-only file; I am not using it and was not able to figure out how
to use it.  I xxencode filename.zip with:

  xxencode filename.zip < filename.zip > filename.xxe 

and xxdecode it with:

  xxdecode filename.xxe

Suggestions welcome.  Thanks.

--David

============================================================
David J. Birnbaum         djb@wjh12.harvard.edu [Internet]
                          djb@harvunxw.bitnet   [Bitnet]
============================================================