cagney@chook.ua.oz (Andrew Cagney - aka Noid) (08/04/90)
Now that we've all recovered from 1.5.{0,3,5,8,9,10} And all those uuencoded
compressed shar archives is there any thing better?
Should we switch to tar or pax or what?
Can things be made more convenient?
Can things be made less convenient :-)
To me it would be nice to be able to take a posting and enter
|magic-command
and have it unpack it exactly where you want it.
Magic-command could be something like:
|modified-uud | tee posting.tar.Z | uncompress | ( cd / ; tar -xf - )
Extracting /etc/passwd
Extracting /etc/groups
:-)
Some thoughts...
1. uuencoding is needed. And for more than just bitnet users
2. Compress -b13 is probably a good idea
3. during the 1.5 upgrade, shar was the cause of several of the
posting problems.
4. How portable is tar?
Any comments?
Andrew Cagneyhyc@math.lsa.umich.edu (Howard Chu) (08/04/90)
In article <1281@sirius.ucs.adelaide.edu.au> cagney@chook.ua.oz (Andrew Cagney - aka Noid) writes: >To me it would be nice to be able to take a posting and enter > |magic-command >and have it unpack it exactly where you want it. I've got a script called "rnget" that worked pretty well for shar files. |rnget <dirname> No sweat, and it left the header/descriptive text in a READ_ME file. >Magic-command could be something like: > |modified-uud | tee posting.tar.Z | uncompress | ( cd / ; tar -xf - ) > Extracting /etc/passwd > Extracting /etc/groups >:-) Actually all you need is "cat part*" in front of the pipeline there... }-) > 1. uuencoding is needed. And for more than just bitnet users atob/btoa is more efficient, why doesn't anyone ever use it? > 2. Compress -b13 is probably a good idea Yeah, doesn't seem too bad. (No great loss not getting 16 bits.) > 3. during the 1.5 upgrade, shar was the cause of several of the > posting problems. Yeah. Could have been avoided by modifying the shar file, to include the uuencoded binary and a uudecode command, instead of the simple catenation... > 4. How portable is tar? I put together my ST upgrade kit on a NeXT machine, tar'ing files back and forth with my ST. No compatibility problems there. I regularly swap tar files across Suns, Vaxes, DECstations, etc. I've never encountered byte-order problems or any other hassles. I think encoded compressed tar files are probably the best way to distribute major source postings. Even though most bitnet sites aren't likely to have tar on-site, the destination machine (a Unix or Minix system) will have all the necessary unpacking tools. -- -- Howard Chu @ University of Michigan one million data bits stored on a chip, one million bits per chip if one of those data bits happens to flip, one million data bits stored on the chip...
cagney@chook.ua.oz (Andrew Cagney - aka Noid) (08/05/90)
From article <1990Aug4.122641.1868@math.lsa.umich.edu>, by hyc@math.lsa.umich.edu (Howard Chu): >>Magic-command could be something like: >> |modified-uud | tee posting.tar.Z | uncompress | ( cd / ; tar -xf - ) > > Actually all you need is "cat part*" in front of the pipeline there... }-) > If you mean cat part* | uud | uncompress | tar -xf - I don't like it :-(. It means that you need every part of a posting before you can unpack it properly. I would prefer things so that I can unpack each part separatly vis for p in part* ; do cat $p | uud | uncompress | tar -xf - ; done ; If a single part went missing I can still unpack the rest. Further, the command could be given from inside news & things can be done in smaller chunks. The problem with the way I'm suggesting is that it is harder to package. a more fancy version of gather being needed. (1. changed to use tar, 2. changed to handle subdirectories, not too hard) >> 1. uuencoding is needed. And for more than just bitnet users > > atob/btoa is more efficient, why doesn't anyone ever use it? I don't think it is as common. A this site only MACH seems to have it :-( However I agree it does seem to be better. > I put together my ST upgrade kit on a NeXT machine Hmm, I've been looking at they way you packaged your kit. I like it (bar the need to have all the parts before you can unpack things). It leads well to doing the entire upgrade mechanically. While as the way I packaged things make is it easy, but tedious, for someone doing the upgrade slowly by hand. If disk space problems are encountered then a full back out is not needed. Some middle ground is needed. See next posting. Andrew Cagney