KEN%ORION.BITNET@wiscvm.wisc.edu (Kenneth Ng) (10/24/87)
>From: Bruce Becker <BECKER%HUMBER.BITNET@wiscvm.wisc.edu> >Uhhh... Ken - what's wrong with using uuencode/compress? Why reinvent the >wheel? These tools are commonly available - do they not meet the need for >BitNet transport? > >Cheers - BBecker Humber College Etobicoke, Ont. If uuencode and compressed worked in ALL cases we wouldn't be having this discussion. I am not aware of the latest version of uuencode, but one early mistake is that one character they took was the space, which some mailers strip (a so-called "feature"). Furthermore, uuencode, as far as I can tell, can not be directly translated on an EBCDIC machine. It has to be first moved to an ASCII machine. Granted, object code would not be very useful, but I believe it is desirable to view source code directly without having to move the file to an ascii machine first. As for compress, the research I've read indicates that the method I'm planning to use is generally better than compress. It is more CPU intensive however, from what I gather. What I'm planning also extends the information on files that are transfered: last modified date/time and record formats for example. Furthermore, I'd like to add the capability for sending several files at once. Before everyone says: "But use share", has anyone ever been burned by a trojan share that did "funny" thinks like removed all your files, send obscene messages to everyone on the system, or renamed all the files under your directory backwards? (e.g. '.profile' became 'eliforp.') Granted I think the last one required some imagination, and it was easy to reverse (just ran the program again), but I no longer trust executing a program off the net. And besides, not everyone has direct access to shell. Why should I discriminate against those who use VM, VMS, MS-DOS, etc? Remember, I'm trying to get my programs to work with the widest possible audience on the widest possible array of systems. Kenneth Ng: ken@orion.bitnet
EXNER%UREGINA1.BITNET@wiscvm.wisc.edu (Art Exner) (10/24/87)
I have versions of fix which ignore whitespace differences and have written
uuencode/uudecode to run on our VM/SP (ebcdic) system. Both are available for
the asking.
Art Exner
University of ReginaBECKER%HUMBER.BITNET@wiscvm.wisc.edu (Bruce Becker) (10/26/87)
1). current versions of uuencode substitute '`' (accent) for " " (space)
in order to deal with problems of blank-stripping - it should not actually
matter for "EOL" strippers, but multiple-blank-collapsers would cause
problems...
2). For every compression method you or I could come up with, there are always
a dozen "better" ones that we never heard of, or don't have a way to
implement, etc...
3). The problem decomposes into about 3 levels - a). archiving like "arc" or
"tar"; b). compression for efficiency; c). transmission media transparency.
So - use "tar" & "compress" to handle a). & b)., AND port "arc" to satisfy
the "BBS" world; c). is solved apprpriately to the transmission system -
x/y-modem, uuencode, etc. The problem with EBCDIC is not serious for
uuencoded files - a simple "ascii-to-Ebcdic" filter is required if not
already provided by the transmission services. Any translation
peculiarities are then resolved in the local version of uuencode/decode...
4). The "gist" of what i'm saying is - please try to build on the existing
universe of utilities as much as you can - that way the "UNix-ness" is
most fully accounted for... Some may say that MINIX now provides the chance
to redo that which Unix tried poorly at - perhaps what you propose falls
into such a category, but I'd like to see more analysis as to what needs
improvement/replacement, etc...
5). So this is an invitation for discussion about the "growth" & enhancement
of MINIX - are my concerns to "bureaucratic", or is such caution useful?
Ken's in the process of putting out something that's going to be a fair
amount of work - I hope he can get as much advice as possible up front...
Cheers, BBecker Humber College Etobicoke, Ont.gnu@hoptoad.uucp (John Gilmore) (10/27/87)
There seems to be a fuss about sending Minix code around. The rest of
the newsgroups seem to be able to send code up down back and forth
without losing it, what's the problem here?
I hear that there are problems with bitnet screwing up messages. It seems
like comp.os.minix is NOT the place to solve these problems. If your site
is getting mangled netnews from a bitnet neighbor, why don't you arrange
with the neighbor to put in a real live transparent link, e.g. by uuencoding
each message or batch that traverses the link and de-encoding it on your end?
If uuencode is not enough to keep it transparent, write a bitnetencode or
something. Plenty of netnews sites that don't have uucp or tcp do this.
Various people have flamed the bitnetfolks for using IBM equipment; the
real problem is that they are using IBM software. They could get UTS
from Amdahl instead and have real Unix and real netnews (running under
VM if they still need to run the crud too). More to the point, they
could patch up the worst of the botches in the IBM software (e.g. write
an ascii-with-newlines file access method, and use it) rather than
trying to get the rest of the world to change. This is not a major
challenge; I know somebody who wrote an OS/MVT access method for
getting at APL file-system files, which are FAR more alien than ascii
text files!
As I understand bitnet it's all leased lines between prearranged hosts,
kind of like usenet is all dialup lines between prearranged hosts. If
you produced some simple software that made the links transparent to
arbitrary binary data, it seems like it would spread like wildfire to
the rest of bitnet, and much of the problem would be over.
--
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
Love your country but never trust its government.
-- from a hand-painted road sign in central Pennsylvaniasbanner1@uvicctr.UUCP (S. John Banner) (10/28/87)
In article <631@louie.udel.EDU> BECKER%HUMBER.BITNET@wiscvm.wisc.edu (Bruce Becker) writes: >3). The problem decomposes into about 3 levels - a). archiving like "arc" or > "tar"; b). compression for efficiency; c). transmission media transparency. > So - use "tar" & "compress" to handle a). & b)., AND port "arc" to satisfy > the "BBS" world; c). is solved apprpriately to the transmission system - > x/y-modem, uuencode, etc. The problem with EBCDIC is not serious for > uuencoded files - a simple "ascii-to-Ebcdic" filter is required if not > already provided by the transmission services. Any translation > peculiarities are then resolved in the local version of uuencode/decode... >4). The "gist" of what i'm saying is - please try to build on the existing > universe of utilities as much as you can - that way the "UNix-ness" is >Cheers, BBecker Humber College Etobicoke, Ont. I must agree with what you are saying, but might I suggest that instead of using tar/compress/arc combinations, that we adopt the 'zoo' program that was distributed on the net a few months ago. It gives the utility of tar (ie, archiving directory structures, etc), with the data compression of arc (actually, in my experiance it tends to be slightly worse than arc, but only by about 2-5 percent, and given the added functionality, I think that that is well worth it), PLUS there are currently versions available for quite a varietly of machines, AND THEY ALL HAVE THE SAME INTERFACE. I think that if we have to set some sort of a standard for this (and I think that we will have do deal with this problem sooner or later), the combination of zoo, and uuencode is probably the way to go. Well, so much for my two cents, if you don't like it, feel free to propose other solutions (preferably with reasons :-), I am open to whatever will get the job done in the best manner for the most people. S. John Banner ...!uw-beaver!uvicctr!sol!sbanner1 ...!ubc-vision!uvicctr!sol!sbanner1 ccsjb@uvvm sbanner1@sol.UVIC.CDN
dick@plx.UUCP (10/30/87)
Summary: Expires: Sender: Followup-To: In article <332@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes: >[...] >I must agree with what you are saying, but might I suggest that instead >of using tar/compress/arc combinations, that we adopt the 'zoo' program >that was distributed on the net a few months ago. It gives the utility >of tar (ie, archiving directory structures, etc), with the data >compression of arc (actually, in my experiance it tends to be slightly >worse than arc, but only by about 2-5 percent, and given the added >functionality, I think that that is well worth it), PLUS there are >currently versions available for quite a varietly of machines, AND THEY >ALL HAVE THE SAME INTERFACE. I think that if we have to set some sort >of a standard for this (and I think that we will have do deal with this >problem sooner or later), the combination of zoo, and uuencode is >probably the way to go. The following may be of relevant interest. . . . Article 1125 of comp.sources.d: Path: plx!sun!amdcad!ames!ptsfa!ihnp4!inuxc!iuvax!bsu-cs!dhesi >From: dhesi@bsu-cs.UUCP (Rahul Dhesi) Newsgroups: comp.sources.d Subject: How to get zoo source/binaries Summary: SAVE THIS ARTICLE--It tells you how to get zoo Message-ID: <1152@bsu-cs.UUCP> Date: 15 Sep 87 02:53:32 GMT Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi) Organization: CS Dept, Ball St U, Muncie, Indiana Lines: 237 I posted the source code for version 1.51 of the zoo archiver to Usenet some time ago. I received several follow-up inquiries about the posted source and also about related sources and binaries. I'm posting the following information here as well as mailing copies to those who inquired via email. There are several ways of getting zoo source and binary files. This information is, however, subject to change with little or no notice. I. Mail me a standard IBM-PC format (360-kilobyte) floppy disk, and enclose a stamped addressed mailer. I will send it back with the current official portable C source code for zoo and all related MS-DOS executables and the AmigaDOS executable. The disk will include the executable zoo for MS-DOS, and all other files will be in zoo archives and may be extracted on any MS-DOS system and then transferred to any other system. (VAX/VMS users: you can also get an executable version for VMS version 4.4 or so if you send two disks instead of one. You will then need to upload the executable zoo to your VMS system using a recent version of VAX/VMS Kermit-32. C-Kermit may not be good enough because it does not understand fixed-length binary formats.) (Pre-compiled binaries are also available for Microport System V/AT, *T&T **IX PC, Xenix/286 3.4 on Intel 310, SCO Xenix 2.2 on AT, System V Release 2 on 3B2, System V Release 3 on 3B2/400, and Xenix/68000 on Radio Shack Model 16, but contact me via electronic mail for specific availability information for the version you need before sending a disk.) Mail the disk(s) to me at this address: Rahul Dhesi 720 West Centennial Avenue #15 Muncie, Indiana 47303 USA II. Simply send me a request for the software, and agree to pass on the software that you receive from me to anybody in your country who sends you blank disk(s) and prepaid mailer as described above, for the next six months, and let me include this information and your name and address in future revisions of this document. I will be happy to send you the software and I will pay for the disk and for the postage and packing. This may be convenient for you if you are not in the USA, but the offer is valid even if you are in the USA. III. Obtain files via anonymous UUCP from site rb442 at 317-285-8661, 1200 bps only, login name "uanon", no password. (Unfortunately not a PC Pursuit area.) Call between 11 pm and 5 am EST only (that's always EST, never EDT, and always 5 hours west of GMT). AT OTHER TIMES THE LINE IS USED FOR VOICE CALLS so be careful. Sample L.sys entry (adjust times for your timezone): rb442 Any2300-0430 ACU 1200 13172858661 "" "" ogin--ogin--ogin--ogin uanon The files are not in the standard /usr/spool/uucppublic area, so you cannot refer to them with just a ~ prefix. You can refer to them as "/usr/spool/uanon/filename" or just as "~uanon/filename". A typical command line might be: $ uucp -r 'rb442!~uanon/z171_src.zoo' '~' Wildcards will not work, so you must separately specify each file you want. Always remember to enclose all strings in quotes as shown, else the tilde (~) may expand (from ksh or csh) to your home directory, and the uucp request may fail. If you have trouble making UUCP work, send me electronic mail at one of these addresses: uunet!bsu-cs!dhesi or dhesi%bsu-cs@uunet.uu.net iuvax!bsu-cs!dhesi pur-ee!bsu-cs!dhesi If you are unable to send electronic mail, you can telephone me at the UUCP number during working hours. LIST OF FILES AVAILABLE FOR UUCP TRANSFER FILES A description of files available -- you are already reading this. It is best to get this file alone first, so you know exactly which files are available, since the information given below may become out-of-date. z171_src.zoo Source code for zoo version 1.71, believed to compile and run on: *T&T **IX PC 3.0 (also known as 3B1); System V Release 2 as exemplified by Microport System V/AT version 2.2; 4.3bsd; Xenix/286; and VAX/VMS. Stored as a zoo archive, so you will need the zoo archiver running on your system to extract this archive. For the same files in text archive form see z171_src.shar. Manuals are not here; see z171_doc.zoo. To use on VAX/VMS you must also get the vmsstuff.zoo files described separately. z171_src.shar Source code for zoo version 1.71, in shell archive form. The contents of this shell archive are identical to those of z171_src.zoo, but can be extracted by executing this archive with the standard Bourne shell or (with some effort) with a text editor. z171_doc.zoo Manual in nroff format; formatted manual; installation notes; and copyright policy. z171_doc.shar Contents are identical to those of z171_doc.zoo, but this is a shar archive. z171_3b1_sh Executable zoo 1.71 for *T&T **IX PC. Compiled under software revision 3.0 and uses shared library, so may not work with other software revisions. z171_3b1_unsh Executable zoo 1.71 for *T&T **IX PC. Compiled under software revision 3.0, but does not use shared library, so should also work with software revisions 3.5 and 3.51. zoo150.exe Zoo 1.50 for MS-DOS. This is a self-extracting archive created with Sez. Execute on an MS-DOS system. It will self-extract the manual and the MS-DOS executable. The resulting zoo executable for MS-DOS can then be used to extract other zoo archives. amiga142b.zoo Zoo 1.42b for Amiga. This zoo archive contains the manual and the AmigaDOS executable. vmsstuff.zoo Support files for VAX/VMS, especially a utility to do file conversions to work around problems related to VMS's file formats. The installation documentation included may be somewhat useful even though it refers to a previous binary-only distribution of zoo for VAX/VMS. See also vmsstuff.shar and vmsstuff.com. vmsstuff.shar Contents identical to those of vmsstuff.zoo but in shell archive format, which may be extracted using the standard Bourne shell or with a text editor. See also vmsstuff.com. vmsstuff.com Contents identical to those of vmsstuff.zoo and vmsstuff.shar, but this is a VMS_SHAR archive in VMS COM format. Execute with the command "@VMSSTUFF" to extract on any version 4.4 or later VMS system. atoz112.zoo Atoz, a program to help automate conversion of archives and libraries in other formats to zoo format. MS-DOS systems only. Executable and documentation. looz210.zoo Looz, a compact program that allows extraction, listing, and execution of files in zoo archives. A file to be executed is extracted directly into memory, so all disks may be write-protected. There is no net memory penalty, because looz removes itself from memory before transferring control to the extracted program. MS-DOS systems only. Executable and documentation. sez230.zoo Sez, a utility to create self-extracting zoo archives. The resulting executable program, when executed on any MS-DOS system, will recreate the contents of the original zoo archive. Self-extraction overhead is less than 2500 bytes. MS-DOS systems only. Executable and documentation. HINTS For use on MS_DOS: Get zoo150.exe, looz210.zoo, atoz112.zoo, and sez230.zoo. For use on any system in the **IX family: Get z171_src.zoo and z171_doc.zoo, or corresponding shar archives. For use on VAX/VMS: Get z171_src.zoo, z171_doc.zoo, and vmsstuff.zoo, or corresponding shar or VMS_SHAR archives. For use on AmigaDOS: Get amiga142b.zoo. In each case, if needed, get zoo150.exe also so you can extract the other zoo archives on any MS-DOS system. CHANGES Changes made in going from zoo version 1.51 to version 1.71: 1. Archive listing commands l and L now accept the following option characters. These are most useful when used in combination with the option character f (fast columnized listing). All meaningful combinations may be used. 1 list in single columns q quieten listing by suppressing headers and trailers / show directory path even in columnized listing 2. Timezone is saved when a file is archived, listed in archive listings, and taken into account when the timestamp of a file is restored at extraction time. 3. VAX/VMS is supported. A makefile for DEC's equivalent of make (called MMS) is supplied. With the help of a file format conversion program that is supplied, zoo archives can be uploaded and downloaded using Kermit, and VMS executable files can be restored to the original record format after extraction from a zoo archive. 4. The comment (c or -comment) commands now list the original filename instead of the filename in MSDOS format. A bug was also fixed that was causing these commands to fail for certain filenames. 5. A bug was fixed that caused a % character in a filename to be interpreted as a printf formatting character in an archive listing. DIRECTORY LISTING The following is a current directory listing of the ~uanon area. protection size, date filename bytes -rw-r--r-- 1 dhesi users 8339 Sep 14 17:12 FILES -r--r--r-- 1 dhesi users 58639 Aug 29 01:01 amiga142b.zoo -r--r--r-- 1 dhesi users 21561 Sep 14 01:18 atoz112.zoo -r--r--r-- 1 dhesi users 14422 Sep 14 01:18 looz210.zoo -r--r--r-- 1 dhesi users 7400 Sep 14 01:18 sez230.zoo -r--r--r-- 1 dhesi users 32070 Sep 14 17:01 vmsstuff.com -r--r--r-- 1 dhesi users 31089 Sep 13 23:26 vmsstuff.shar -r--r--r-- 1 dhesi users 15241 Aug 2 00:15 vmsstuff.zoo -r-xr-xr-x 3 dhesi users 34202 Sep 13 23:12 z171_3b1_sh -r-xr-xr-x 2 dhesi users 49618 Sep 13 23:16 z171_3b1_unsh -r--r--r-- 1 dhesi users 58531 Sep 14 02:37 z171_doc.shar -r--r--r-- 1 dhesi users 26346 Sep 14 02:13 z171_doc.zoo -r--r--r-- 1 dhesi users 270705 Sep 13 22:30 z171_src.shar -r--r--r-- 1 dhesi users 128711 Sep 13 22:22 z171_src.zoo -r--r--r-- 1 dhesi users 44848 Aug 29 01:01 zoo150.exe -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi -- Dick Flanagan, W6OLD I'll take a drug test when UUCP: ...!ucbvax!sun!plx!dick Reagan takes an IQ test. GEnie: FLANAGAN
randy@umn-cs.UUCP (Randy Orrison) (11/02/87)
In article <332@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes: > I think that if we have to set some sort >of a standard for this (and I think that we will have do deal with this >problem sooner or later), the combination of zoo, and uuencode is >probably the way to go. How about a modification to zoo: Have it produce btoa'd output, and recognize that transparently as input? I haven't gotten it running on this Encore yet, but it doesn't seem like a text header giving the format (8 bit or btoa'd) would be unreasonable. Anyone want to work on this? (I would, but like I said i haven't even had time to find the bug that dumps core here...) (btoa: like uuencode, but adds only 20% to size) > S. John Banner > >...!uw-beaver!uvicctr!sol!sbanner1 >...!ubc-vision!uvicctr!sol!sbanner1 >ccsjb@uvvm >sbanner1@sol.UVIC.CDN -randy -- Randy Orrison, University of Minnesota School of Mathematics UUCP: {ihnp4, seismo!rutgers!umnd-cs, sun}!umn-cs!randy ARPA: randy@ux.acss.umn.edu (Yes, these are three BITNET: randy@umnacca different machines)
rmtodd@uokmax.UUCP (Richard Michael Todd) (11/02/87)
In article <332@uvicctr.UUCP> sbanner1@uvicctr.UUCP (S. John Banner) writes: >I must agree with what you are saying, but might I suggest that instead >of using tar/compress/arc combinations, that we adopt the 'zoo' program >that was distributed on the net a few months ago. It gives the utility >of tar (ie, archiving directory structures, etc), with the data .... >ALL HAVE THE SAME INTERFACE. I think that if we have to set some sort >of a standard for this (and I think that we will have do deal with this >problem sooner or later), the combination of zoo, and uuencode is >probably the way to go. I agree with you about the usefulness of Zoo. I use it all the time to transport files from this machine, an Encore Multimax, to my PC. The source for Zoo compiled and ran first time on the Multimax, which is more than I can say for many other programs from the net. There is, however, a problem with using it on MINIX. Some time ago I corresponded with Rahul Dhesi about porting Zoo to MINIX, and he told me that it won't fit in 64Kcode-64Kdata systems. Considering that a full 13-bit LZW compression table takes around 50K, this isn't too surprising. So, Zoo won't fit on MINIX. However, the 'booz' (I believe that's its name) simplified extract-only program probably will work on MINIX; in fact, it was designed to be portable to limited-memory systems. So, though you won't be able to create Zoo archives on MINIX, it will be possible to extract them on MINIX. Ain't great, but better than nothing. -------------------------------------------------------------------------- Richard Todd "MSDOS: Just Say No" USSnail:820 Annie Court,Norman OK 73069 UUCP: {allegra!cbosgd|ihnp4}!occrsh!uokmax!rmtodd