andy@mks.com (Andy Toy) (02/14/90)
What will we use? We have used or are using arc, zoo and
uuencode/uudecode. Should we change to something new or avoid the
hassle of yet another change? If we are going to change (or not) then
let's see what we have to work with. Please make comments and
additions about the following lists.
Let me list the archive programmes that might be used:
arc,pkarc,pkpak,...
zoo
pkzip
lharc
tar,cpio,shar/compress
Some important factors include portability, compression ratio, speed,
and ease of use.
Some of the possible encoding/decoding schemes that are available are:
uuencode/uudecode
atob/btoa
abe
xxencode/xxdecode
Considerations include portability, expansion ratio, ability to handle
multiple parts, keep clear text intact, and effect of network gateways.
I make some comments in a followup.
--
Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com
35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy
Ontario, CANADA N2J 2W9 Phone: 519-884-2251 FAX: 519-884-8861cs480125@umbc5.umbc.edu (Peter Johansson) (02/15/90)
In article <1990Feb14.154555.2435@mks.com> andy@mks.com (Andy Toy) writes: >What will we use? We have used or are using arc, zoo and >uuencode/uudecode. Should we change to something new or avoid the >hassle of yet another change? If we are going to change (or not) then >let's see what we have to work with. Please make comments and >additions about the following lists. [[[ lists deleted ]]] >Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com I would like to make an addition to the current choices, if for no other reason than the sake of completeness. Does there exist a single program to turn a collection of files directly into a {UU|XX}ish format? Or put another way, an archiver that saves files in text format. This reduces the amount of work required to re-create the origonal fileset, which, at least in theory, could reduce some of the everpresent confusion to new c.b.i.p. readers. If such a program does not already exist (which I doubt) the library of public, portable, source code for compression and binary to text conversion is large enough such that this is not a large task. To be sure, not nearly as large a task as to convince the c.b.i.p. audience to make use of it. Of course, the whole point is moot until the files start flowing again - But wait, what was that? Did I just see a little trickle??? -- Peter Johansson cs480125@umbc5.umbc.edu I suppose if I was a witty person I would say something witty here.
a864@mindlink.UUCP (Jono Moore) (02/15/90)
> rwh writes: > > Msg-ID: <1990Feb15.205313.7334@me.toronto.edu> > Posted: 16 Feb 90 01:53:14 GMT > > Org. : none > Person: Russ Herman > > One advantage to PKZIP amd ZOO that no-one has mentioned yet is their > ease of handling nested directories. ZIP is a tad easier because you > can do it all from the command line, but a one-liner invoking 'find' > generates the file list for zoo aI.. Until we see a ZIP-clone, freeware, > for all the non-PC world, I'm in favour of staying with ZOO (even though > the first thing I do after D/L is convert to ZIP). > > Russ Herman > INTERNET: rwh@me.utoronto.ca UUCP: ..uunet!utai!me!rwh LHARC also handles nested subdirectories quite easily -rp to archive I believe and -r when extracting. -- {a864,Jono_Moore}@mindlink.UUCP >or< BITNET: usernk1z@sfu (604) 983-3189 (voice) OTHER: Jono_Moore@cc.sfu.ca (604) 983-3546 3/12/2400 (Cthulhu's Progressive Link - MSDOS only) "Don't you know there ain't no devil, it's just god when he's drunk." - Tom Waits
rwh@me.utoronto.ca (Russ Herman) (02/16/90)
One advantage to PKZIP amd ZOO that no-one has mentioned yet is their ease of handling nested directories. ZIP is a tad easier because you can do it all from the command line, but a one-liner invoking 'find' generates the file list for zoo aI.. Until we see a ZIP-clone, freeware, for all the non-PC world, I'm in favour of staying with ZOO (even though the first thing I do after D/L is convert to ZIP). I think the more serious problem is around encoders, what with EBCDIC and international character sets. UU doesn't cut it in that broader perspective. Russ Herman INTERNET: rwh@me.utoronto.ca UUCP: ..uunet!utai!me!rwh
andy@mks.com (Andy Toy) (02/17/90)
In article <1990Feb14.154555.2435@mks.com> I (Andy Toy) write: > arc,pkarc,pkpak,... .ARC archives have been around for a while, but cbip switched away from arc due to its cloudy future. Its shareware nature and the SEA vs PKware lawsuit sure caused a stir. However it is quite a popular format and versions are available for quite a few OS despite the introduction of compression formats (squashing) that caused compatiblity problems with the originator's version. Squashing did get added to arc though. Do we want to use a shareware archiver? > zoo Zoo is free and available on many OS. It is slower and does not compress as well as PK..., but better compression schemes could be added. It is being used NOW so it is easier to just stay with it. > pkzip Good programme, but not available for as many OS as arc and zoo. I cannot remember which OS zip/unzip was being developed for. I vaguely remember DOS (OS/2), VMS and AmigaDOS? There is an unzip programme available for BSD UNIX, but that doesn't help much if you want top put these ZIP files together on your BSD (or SYS V) UNIX system. Is cbip going to run into problems because of the shareware issue again? > lharc I don't know much about this, but there seems to be a lack of archivers using this compression scheme for DOS and UNIX. > tar,cpio,shar/compress This is the traditional UNIX distribution format, but it's not very suitable for DOS. Of course there are DOS versions of all these programmes. However it is rather cumbersome to deal with compressed archives of this nature. > uuencode/uudecode The advantage of this is its widespread availablility due to its inclusion in UNIX. It's been ported to various OS. One of its problems is that it uses characters that can get mapped improperly when passing through non-ASCII sites. > atob/btoa This has been used on UNIX too, but I can't remember its lineage. > abe This is Brad Templeton's new-fangled programme which seems to do exactly what we want probably because he had cbip in mind when he wrote it (thanks Brad). It's compatible with uuencode, and has lots of neat features and additional coding schemes (see Brad's posting in this newsgroup). > xxencode/xxdecode It's seems to be an improved uuencode/uudecode, but is not as widespread as it's predecessor. It doesn't have the problems that uu{en,de}code has with non-ASCII sites (that's what I hear). There are some others that I just though of that are used such .BOO files as found in Columbia's kermit area, binhex which is used a lot in Mac(?) circles. My preference? I would always tend to go with the free software as long as it is portable enough to have it work on all the relevant OS platforms. If source code is available then users can fix/add/improve things and pass these along to the author. I would choose zoo and abe. If there are deficienies, we can fix them. -- Andy Toy, Mortice Kern Systems Inc., Internet: andy@mks.com 35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy Ontario, CANADA N2J 2W9 Phone: 519-884-2251 FAX: 519-884-8861
andre@targon.UUCP (andre) (02/20/90)
In article <1990Feb14.154555.2435@mks.com> andy@mks.com (Andy Toy) writes: >What will we use? We have used or are using arc, zoo and >uuencode/uudecode. Should we change to something new or avoid the >hassle of yet another change? If we are going to change (or not) then >let's see what we have to work with. Please make comments and >additions about the following lists. >Let me list the archive programmes that might be used: > arc,pkarc,pkpak,... > zoo > pkzip > lharc > tar,cpio,shar/compress >Some important factors include portability, compression ratio, speed, >and ease of use. >Some of the possible encoding/decoding schemes that are available are: > uuencode/uudecode > atob/btoa > abe > xxencode/xxdecode >Considerations include portability, expansion ratio, ability to handle >multiple parts, keep clear text intact, and effect of network gateways. My opinion is that we should keep using UU[de][en]code because we know that it works (tested it for the last few years) many people have unpack scripts that take news articles that use uudecode to unpack and it is availlable almost everywhere. My second vote would go to [ab]to[ba] as it is everywhere where news is although probably not on many pc systems. As for the archiver to be used, ZOO is my choice because it works on many platforms, and I can test and re-pack archives on unix if I want (I use unix tapes for backup of some pc stuff). Also, I think a newsgroup should never force it's readers to use software that is not free. Finally, not so very long ago we had a poll on what to use, the outcome was zoo. Why is it that this discussion has to come up every few months? Do we have some sore losers in our midst ? :-) -- The mail| AAA DDDD It's not the kill, but the thrill of the chase. demon...| AA AAvv vvDD DD Ketchup is a vegetable. hits!.@&| AAAAAAAvv vvDD DD {nixbur|nixtor}!adalen.via --more--| AAA AAAvvvDDDDDD Andre van Dalen, uunet!hp4nl!targon!andre
bobmon@iuvax.cs.indiana.edu (RAMontante) (02/21/90)
david@csource.oz.au (david nugent) <74.25E169A8@csource.oz.au> : - > > xxencode/xxdecode - -Where can one obtain theses? Around here they say you have to write your own... :-)
rreiner@yunexus.UUCP (Richard Reiner) (02/21/90)
bobmon@iuvax.cs.indiana.edu (RAMontante) writes: >david@csource.oz.au (david nugent) <74.25E169A8@csource.oz.au> : >- > > xxencode/xxdecode >- >-Where can one obtain theses? >Around here they say you have to write your own... :-) I have C source for 'em. Ask and ye shall receive. --Richard -- Richard J. Reiner rreiner@nexus.yorku.ca BITNET: rreiner@yorkvm1.bitnet (also rreiner@vm1.yorku.ca)
david@csource.oz.au (david nugent) (02/21/90)
> > xxencode/xxdecode > > It's seems to be an improved uuencode/uudecode, but is not as > widespread as it's predecessor. It doesn't have the problems that > uu{en,de}code has with non-ASCII sites (that's what I hear). Where can one obtain theses? david -- _--_|\ FidoNet <-> ACSNET Gateway, Melbourne, Australia / \ Central Source iCBS / Unique Computing Pty Ltd \_.--._/ UUCP: ...!munnari!csource!david FidoNet 3:632/348 v Internet: david@csource.oz.au
wales@valeria.cs.ucla.edu (Rich Wales) (02/21/90)
In article <36517@iuvax.cs.indiana.edu> bobmon@iuvax.cs.indiana.edu (RAMontante) writes: david@csource.oz.au (david nugent) <74.25E169A8@csource.oz.au> : - > > xxencode/xxdecode - -Where can one obtain theses? Around here they say you have to write your own... :-) Lest anyone might miss Bob's joke, prompted by David's innocent typo, and conclude that the "XX" programs are not available: Get file PD1:<MSDOS.FILUTL>XXCP.ARC (151K bytes) from SIMTEL20. I was able to compile the XXENCODE.C and XXDECODE.C sources from this file on my Sun-3 workstation (running SunOS 4.0) without change. Essentially, the only difference between XXENCODE and UUENCODE is that, whereas UUENCODE uses the following character output function -- #define ENC(c) (((c) & 077) + ' ') -- XXENCODE uses the following function -- #define ENC(c) ( set[ (c) & 077 ] ) static char set[] = "+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz"; Except for the character set used, the two programs are identical. I would strongly recommend, by the way, that we switch from UUENCODE to XXENCODE. It is a trivial sacrifice for the majority of us to pay so that the minority who are stuck behind ASCII-munging BITNET machines can have a chance to use the material in this newsgroup. -- Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683 "Then they hurl heavy objects. . . . And claw at you. . . ."
brad@looking.on.ca (Brad Templeton) (02/21/90)
ABE can store multiple files, but it is not really an archiver -- ie. the only operation is "extract all." I advise that a compressing archiver is not what is desired. Compression is the duty of the news transport mechanism, by and large. Almost all USENET links that care compress, and use better compression than found in the 12 or 13 bit LZ of ARC. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
roy@comcon.UUCP (Roy M. Silvernail) (02/21/90)
In article <99623@looking.on.ca>, brad@looking.on.ca (Brad Templeton) writes: > I advise that a compressing archiver is not what is desired. Compression > is the duty of the news transport mechanism, by and large. Almost all > USENET links that care compress, and use better compression than found in > the 12 or 13 bit LZ of ARC. Remember, though, that we're transporting binaries, which will have to be encoded somehow. (xx or uu) Since the postings have to reside on disks, if the binaries are compressed before encoding, they consume less static space. I think a multi-platform compressing archiver _is_ the ticket. (and I lean toward LHarc. wish it were ported to more Unix platforms) The transport layer, however, does not compress. It encodes, packetizes and must be reassembled. Your description of ABE sounds like the right compliment to a good compressing archiver. -- _R_o_y _M_. _S_i_l_v_e_r_n_a_i_l | UUCP: uunet!comcon!roy | "Every race must arrive at this #include <opinions.h>;#define opinions MINE | point in its history" SnailMail: P.O. Box 210856, Anchorage, | ........Mr. Slippery Alaska, 99521-0856, U.S.A., Earth, etc. | <Ono-Sendai: the right choice!>
bobmon@iuvax.cs.indiana.edu (RAMontante) (02/21/90)
->- > > xxencode/xxdecode
->-
->-Where can one obtain theses?
^^^^^^
-bobmon@iuvax.cs.indiana.edu (RAMontante) writes:
->Around here they say you have to write your own... :-)
rreiner@yunexus.UUCP (Richard Reiner) <7806@yunexus.UUCP> :
-
-I have C source for 'em. Ask and ye shall receive.
Great! Will it compile to titles like "VLSI Implementation of Analog
Neural Nets"? I need about 10 chapters...
:-) :-)ts@uwasa.fi (Timo Salmi LASK) (02/22/90)
In article <1047@targon.UUCP> andre@targon.UUCP (andre) writes: > >Finally, not so very long ago we had a poll on what to use, >the outcome was zoo. Why is it that this discussion has to come >up every few months? Do we have some sore losers in our midst ? :-) The reason for the discussion is simple this time. Since c.b.i.p. was dormant for a long time before the activities started again, we wanted to check whether essential new information had come about in between. The result was that it best to continue with zoo and uuencode, for two reasons. First because our new moderator wanted it this way, and he is the person who must be given the final say. If not, anarchy may follow. Second it is obvious that even if these two methods are not perfect (what is anyway) the netters have the necessary tools from Rahul's time, and the 'cost' of any change would have been great. So far, all the postings have discussed the matter in a rational way. No losers, or whatever, sore or otherwise have been in evidence. P.S. I know that you said it jokingly, and I only say this in case somebody feels offended, nevertheless. I certainly don't (but I haven't lost nor won anything either). ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
ray@ole.UUCP (Ray Berry) (02/22/90)
In article <32123@shemp.CS.UCLA.EDU> wales@CS.UCLA.EDU (Rich Wales) writes:
-- XXENCODE uses the following function --
#define ENC(c) ( set[ (c) & 077 ] )
static char set[] =
"+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
Except for the character set used, the two programs are identical.
<end of quote>
Kudos to Rich for contributing useful data. Similarly,
static unsigned char xx[] = {
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,
255,255,255,255,255,255,255,255,255,0,255,1,255,255,2,3,4,5,6,7,8,
9,10,11,255,255,255,255,255,255,255,12,13,14,15,16,17,18,19,20,21,
22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,255,255,255,255,255,
255,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,
59,60,61,62,63,255,255,255,255,255};
/* array 'xx' has 128 members */
#define DEC(c) xx[(c)&127]
would seem to transform uudecode into xxdecode. I offer this not as a
profound intellectual divination, but simply for those too lazy to type.
--
Ray Berry kb7ht uucp: ...ole!ray CIS: 73407,3152 /* "inquire within" */
Seattle Silicon Corp. 3075 112th Ave NE. Bellevue WA 98004 (206) 828-4422brad@looking.on.ca (Brad Templeton) (02/22/90)
If the encoder is going to be changed, a switch to xxencode seems pointless. All it fixes is the use of some characters that ebcdic translations munge. 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. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
Jerry.Andrews@f426.n109.z1.fidonet.org (Jerry Andrews) (02/22/90)
RW> whereas UUENCODE uses the following character output function -- RW> RW> #define ENC(c) (((c) & 077) + ' ') How do I apply this funtion to the source file to get an output file? Looks to me like, if this function is applied to each byte of the source file, you'd wipe all the hi bits, and not end up with a complete set of printable characters anyway... (I feel kinda stupid here... ;) ) -- Jerry Andrews at The Black Cat's Shack (Fidonet 1:109/401) Internet: Jerry.Andrews@f426.n109.z1.fidonet.org UUCP: ...!uunet!blkcat!426!Jerry.Andrews
djb@wjh12.harvard.edu (David J. Birnbaum) (02/22/90)
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] ============================================================
alawlor@dit.ie (Aengus Lawlor) (02/23/90)
I downloaded the PAX program yesterday from cbip. I had requested it from
SIMTEL only about 2 weeks ago, so I decided to make a comparison.
SIMTELs file was ARCed. The cbip file was ZOOed. I ZIPped the files
for comparison.
I didn't do a time comparison, but these figures indicate a ~25% saving in
file size, and if cbip ever gets real busy again, that figure has to be
significant!
Given that it's PC only code, the UNIX compatibility issue must be weighed
against this bandwidth saving.
Data follows----
C:\COMMS\PAX >dir pax
Volume in drive C has no label
Directory of C:\COMMS\PAX
PAX ARC 64128 9-02-90 12:24p
PAX ZIP 47103 22-02-90 4:39p
PAX ZOO 62165 22-02-90 4:34p
3 File(s) 3604480 bytes free
C:\COMMS\PAX >pkarc -v pax
PKARC FAST! Archive Create/Update Utility Version 3.5 04-27-87
Copyright (c) 1986,1987 PKWARE Inc. All Rights Reserved. PKARC/h for help
Searching Archive: PAX.ARC
Filename Length Method Size Ratio Date Time CRC
-------- ------ ------ ------ ----- ---- ---- ---
CPIO.MAN 7004 Crunched 3347 53% 02-15-89 11:03:30 0DDD
PAX.MAN 15588 Crunched 6411 59% 02-15-89 11:02:16 307C
README.DOS 1790 Crunched 1176 35% 02-15-89 11:21:16 685A
TAR.EXE 65737 Crunched 50371 24% 02-15-89 10:54:34 EC29
TAR.MAN 5761 Crunched 2630 55% 02-15-89 11:02:54 98FC
---- ------ ------ -----
0005 95880 63935 34%
C:\COMMS\PAX >pkzip -v pax
PKZIP (tm) FAST! Create/Update Utility Version 1.02 10-01-89
Copyright 1989 PKWARE Inc. All Rights Reserved. PKZIP/h for help
Searching ZIP: PAX.ZIP
Length Method Size Ratio Date Time CRC-32 Attr Name
------ ------ ----- ----- ---- ---- ------ ---- ----
7004 Implode 2684 62% 02-15-89 11:03 7042a227 --w CPIO.MAN
15588 Implode 5197 67% 02-15-89 11:02 ac281a0e --w PAX.MAN
1790 Implode 970 46% 02-15-89 11:21 3d15390a --w README.DOS
65737 Implode 35544 46% 02-15-89 10:54 19b8c29b --w TAR.EXE
5761 Implode 2228 62% 02-15-89 11:02 36d5857b --w TAR.MAN
------ ------ --- -------
95880 46623 52% 5
C:\COMMS\PAX >looz l pax
Archive pax.zoo:
Length CF Size Now Date Time
-------- --- -------- --------- --------
7004 52% 3373 20 Feb 90 23:07:46 CPIO.MAN
15588 58% 6504 20 Feb 90 23:07:48 PAX.MAN
1790 34% 1175 20 Feb 90 23:07:48 README.DOS
65737 27% 47970 20 Feb 90 23:08:00 TAR.EXE
5761 53% 2690 20 Feb 90 23:08:00 TAR.MAN
-------- --- -------- --------- --------
95880 36% 61712 bytes, 5 file(s)
--
Aengus Lawlor Dept of Computer Science. Time flies like an arrow,
ALAWLOR@DIT.IE Dublin Institute of Technology. Fruit-flies like a banana
Kevin Street. Dublin 8. Ireland. wales@valeria.cs.ucla.edu (Rich Wales) (02/23/90)
In article <522.25E37FEB@blkcat.fidonet.org> Jerry.Andrews@f426.n109.z1.fidonet.org (Jerry Andrews) writes: RW> whereas UUENCODE uses the following character output RW> function -- RW> RW> #define ENC(c) (((c) & 077) + ' ') How do I apply this funtion to the source file to get an output file? Looks to me like, if this function is applied to each byte of the source file, you'd wipe all the hi bits, and not end up with a complete set of printable characters anyway... I wrote my article with the underlying assumption that the people who would read it had a thorough understanding of how UUENCODE works. Since this assumption may not have been fair, let me elaborate. UUENCODE takes sets of three 8-bit bytes, rearranges the bits into four 6-bit groups, and translates each of these 6-bit groups into a printa- ble ASCII character. Additionally, each line of output from UUENCODE starts with a one-byte count of the number of 8-bit bytes encoded in that line. The reason most lines in a UUENCODE file start with the capital letter "M" is that this letter corresponds to the number 45 in UUENCODE's scheme -- and most of the lines in a UUENCODE file contain 61 printable characters (the initial "M", plus 60 characters that correspond to 45 8-bit bytes). The "character output function" I described in my article is what UUEN- CODE uses to translate its 6-bit groups into printable characters. I should probably have added that some UUENCODE's output a grave accent (`) instead of a space -- as protection against some mail systems that strip trailing blanks from lines in messages. The only real difference between UUENCODE and XXENCODE is in the func- tion that translates 6-bit groups into printable characters. Some of the characters used by UUENCODE (punctuation marks such as the square brackets, curly braces, and backslash) get destroyed -- translated into question marks, or deleted altogether -- by many machines which use IBM's EBCDIC character set. This is why lots of people have been objecting to UUENCODE and asking for some other program to be used in its place. XXENCODE uses a different set of printable characters that aren't disturbed by any known ASCII/EBCDIC translation schemes in use on USENET. -- Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683 "Then they hurl heavy objects. . . . And claw at you. . . ."
brad@looking.on.ca (Brad Templeton) (02/23/90)
In article <448@wjh12.harvard.edu> djb@wjh12.UUCP (David J. Birnbaum) writes: >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. DABE does not require the parts in any particular order, if the encoding was made with redundant headers, as I would expect multi-part postings to this group to be. While it is true that under DOS you can't do dabe *.abe because I wanted to keep dabe as 99% portable code, not full of ifdefs and special OS calls, you can do dabe file4 file1 file3 file2 or somecat file* | dabe if 'somecat' is a smart DOS cat that handles patterns. This handling of patterns should not go in every program, if we can avoid it. In a imple case like this (catting) we can. Is it better to break the purity of the DABE code (currently only 4 short ifdefs for setting file modes/times etc.) to add DOS directory scans? -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
joefritz@pawl.rpi.edu (Jochen M. Fritz) (02/23/90)
In article <448@wjh12.harvard.edu> djb@wjh12.UUCP (David J. Birnbaum) writes: >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 The uuencode/decode I have (V3.07 by Richard Marks, PC) will fragment files automatically, and even automatically put them pack together. This is done such that if a file has a number in it, it will try to load an idectical file with the next number. EX: you tell it to decode part1.uue; after it finished, it attempts to decode part2.uue, and so on. I believe that I got it from either Simtel20 or Grape. -- ------------------------------------------------------------------------ | Jochen Fritz | For though we live in the world, we do not | | joefritz@pawl.rpi.edu | wage war as the world does.-- 2 Cor. 10:3 | | usergk2s@rpitsmts.bitnet| You have heard it said, Love your neighbor |
djb@wjh12.harvard.edu (David J. Birnbaum) (02/23/90)
In article <{#^#GY@rpi.edu> joefritz@pawl.rpi.edu (Jochen M. Fritz) writes: (in response to my noting that DABE was the only uudecode alternative that included the ability to reassemble multiple part files): >The uuencode/decode I have (V3.07 by Richard Marks, PC) will fragment files >automatically, and even automatically put them pack together. This is a useful feature of Richard's uuencode/uudecode. But my original posting referred to uuencode *alternatives*, since uuencoded files are useless for transmission between many ASCII and EBCDIC sites. Of the programs that use safer encoding schemes, only ABE automatically generates multiple parts. Richard's earlier posting announcing that he hoped to add xx coding as an alternative to his program will provide another system that combines safe coding with automatic splitting and recombination. Thanks also for Brad's clarification to my posting about the way DABE deals with multiple-part files under MS-DOS. I originally stated inac- curately that DABE could not decode multiple-part files under MS-DOS if the parts were out of order. What I should have said was that it can't expand wildcards; MS-DOS users need something like 'cat' to com- bine all the pieces, but DABE will sort them out even if they are not in order. Users with aliasing capabilities and a smart MS-DOS cat can redefine DABE as 'cat %& | dabe', where %& passes all command line parameters to the alias. This is the syntax in 4dos; CED and others may vary. This will effectively add wildcard capabilities to the MS-DOS implemen- tation of DABE without requiring any changes in the code. --David ============================================================ David J. Birnbaum djb@wjh12.harvard.edu [Internet] djb@harvunxw.bitnet [Bitnet] ============================================================
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (02/24/90)
In article <7273.25e41a7a@dit.ie> alawlor@dit.ie (Aengus Lawlor) writes: | Given that it's PC only code, the UNIX compatibility issue must be weighed | against this bandwidth saving. As soon as the free UNIX version of zip is available I'll take a look at it. Until then, the ability to check the archive on UNIX, to do a directory and check the dates, to extract a single doc file and read it, represents a strong reason to stay where we are. We could always go to ffark (fast-fast-archiver) and compress, which gives better compression in virtually every case. I don't plan on that, either. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc "Getting old is bad, but it beats the hell out of the alternative" -anon
rreiner@yunexus.UUCP (Richard Reiner) (02/25/90)
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes: > We could always go to ffark (fast-fast-archiver) and compress, which >gives better compression in virtually every case. Better than Arc, yes. Better than Zip, no. Not even close. --Richard -- Richard J. Reiner rreiner@nexus.yorku.ca BITNET: rreiner@yorkvm1.bitnet (also rreiner@vm1.yorku.ca)
rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) (02/27/90)
When we think about switching from uuencode to another encode, we should use a program in the future which does not only change the encoding scheme and is still as simple as uuencode is and does not support multiple volumes, CRC's and so on. Therefore I would suggest to use the ABE program because it is a nice program which is easy to compile on most systems and offers a lot of capabilities. Don't use this dumb uu/xx-encode programs any more when better software is available. Kai Uwe Rommel Munich rommel@lan.informatik.tu-muenchen.dbp.de
frotz@drivax.UUCP (Frotz) (02/27/90)
brad@looking.on.ca (Brad Templeton) writes:
] Is it better to break the purity of the DABE code (currently only 4 short
] ifdefs for setting file modes/times etc.) to add DOS directory scans?
Actually, depending on your compiler, you might want to add
the support via opendir(), readdir(), closedir(). I have a tendency
(picked up from Rahul's code) to have separate modules for each
platform. Local rumor has it that I have the source for the Turbo C
2.0 opendir/readdir/closedir functionality. I have not actually cut
any of my code over from the traditional Turbo C 2.0 MSDOS Functions,
but I requested a port of the functions that Wayne Davison
(davison@drivax.UUCP) did for a DOS--OS/2 port of GNUDiff (MSC 5.1) so
that I could eliminate some code in one of my projects. It is
available for any takers with the proviso that I have not tested it
personally.
If this is not an option, then I would "MS-DOS? 'Just say
No!'"
--Frotz @Digital Research, Incorporated amdahl!drivax!frotz
70 Garden Court, B15 (408) 649-3896
Monterey, California 93940 Ask for John Fa'atuai