elee24@castle.ed.ac.uk (H Bruce) (07/18/90)
Does anyone have an automated way of extracting programs from the postings in comp.binaries.ibm.pc ? Ideally this would order the postings correctly (they sometimes appear in the wrong order) and extract and concatenate the uuencoded text. Thanks Henry Bruce
sonny@charybdis.harris-atd.com (Bob Davis) (07/19/90)
In article <5213@castle.ed.ac.uk> elee24@castle.ed.ac.uk (H Bruce) writes: >Does anyone have an automated way of extracting programs from the postings in >comp.binaries.ibm.pc ? >Ideally this would order the postings correctly (they sometimes appear in the >wrong order) and extract and concatenate the uuencoded text. > >Thanks > >Henry Bruce I don't recall from what forum I copied this off the net, but the following alias has worked to perfection for me. I have only to copy all parts of a posting: say POST1, POST2, POST3 to a given directory in which NO OTHER FILES RESIDE and then, in that directory, to issue the command: massuud which I have aliased to: massuud: aliased to cat * | sed /^END/,/^BEGIN/d | uudecode The files are miraculously concatenated together, everything NOT between the BEGIN and END lines of each posting is discarded; and finally, the residue is UUDECODED. This last operation virtually always--here on cbip, anyway--results in a *.zoo file. One then simply has to apply Rahul Dhesi's "unzoo-er" to extract the original files. It is quite simple (but ONLY after you have done it successfully one time!). Good luck... And, Peace. ______________________________________________________________________________ Bob Davis \\\INTERNET : sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\\ UUCP : ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\\AETHER : K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\\VOICE : (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\\ FAX : (407) 729-2537 | FOR MYSELF. |_________|
nelson@sun.soe.clarkson.edu (Russ Nelson) (07/19/90)
I changed this a little because I don't have brik, plus I tried to
make it check the checksum of the file using zoo, but I don't have the
right filename or something... Also, I keep a copy of the first
article up to the begin line, and I add that to the article by hand
(although it would be better to do it automatically). Anyway, if
someone gets that to work, I'd appreciate a copy.
-russ
#!/bin/sh
# $(#) pibm -- save c.b.i.p. articles -- Andre van Dalen, andre@targon
# Save postings from comp.binaries.ibm.pc
#
tmp=/tmp/pibm$$
cd /usr/local/News/ibm
cat - > $tmp
#if brik -cv < $tmp
#then
# echo Checksum OK..
#else
# echo Checksum NOT OK!!! File not saved!
# exit 1
#fi
#subject=`grep '^Subject:' $tmp`
#part=`echo $subject | sed -n 's:^.*[Pp]art \([0-9][0-9]*\)/.*$:\1:p'`
#last=`echo $subject | sed -n 's:^.*[Pp]art [0-9][0-9]*/\([0-9][0-9]*\).*$:\1:p'`
#name=`echo $subject | sed 's/Subject: v[^:]*: \([^, ]*\)[, ].*/\1/'`
archnam=`grep '^Archive-name:' $tmp`
subject=`grep '^Subject:' $tmp`
part=`echo $subject | sed -n 's:^.*[Pp]art *\([0-9][0-9]*\)/.*$:\1:p'`
last=`echo $subject | sed -n 's:^.*[Pp]art *[0-9][0-9]*/\([0-9][0-9]*\).*$:\1:p'`
name=`echo $archnam | sed -e 's/Archive-name: \([^, ]*\).*/\1/' \
-e 's:/[Pp]art[0-9][0-9]*::' | tr '/' '_' `
txtname=`echo $archnam | sed -e 's/Archive-name: //' -e 's/\(\/\).*$//'`
save=ibm/$name.$part
lastsave=ibm/$name.$last
#echo name $name part $part last $last save $save lastsave $lastsave
#exit
if [ "$part" = "" ]
then
echo One part posting, uudecoding...
cd ibm
cat $tmp | sed '/^BEGIN/,$d' > $txtname.hdr
/usr/local/public/bin/uudec < $tmp
chmod 664 $txtname.zoo
else
echo Multi part posting, saving as $save
if [ -f $save ]
then
echo $save already exists! not saved.
else
cp $tmp $save
nr=`ls ibm/$name.[0-9][0-9] | wc -l`
echo Now we have $nr out of $last parts
if [ -f $lastsave -a $nr -eq $last ]
then
echo Last part, try to combine...
cd ibm
cat $name.01 | sed '/^BEGIN/,$d' > $txtname.hdr
list=`echo " " $name.* " " | sed 's/ [^ ]*[^0-9 ] / /g'`
echo "$list -> " \\c
# brik -cv $list
cat $list | sed '/^END--/,/^BEGIN--/d' | /usr/local/public/bin/uudec
echo $name*.[aze]*
chmod 664 $txtname.zoo
echo mv $name.[0-9][0-9] old
mv $name.[0-9][0-9] old
fi
fi
fi
rm $tmp
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
In Communism's central planning, citizens are told "you will make widgets".
In Capitalism's advertising, citizens are told "you will buy widgets".mrh@camcon.co.uk (Mark Hughes) (07/19/90)
elee24@castle.ed.ac.uk (H Bruce) writes: >Does anyone have an automated way of extracting programs from the postings in >comp.binaries.ibm.pc ? >Ideally this would order the postings correctly (they sometimes appear in the >wrong order) and extract and concatenate the uuencoded text. I use the following Unix shell script with the newsreader nn (which orders the postings for me): tee /tmp/mrhuuj$$ | sed -e '/^END--cut here/,/^BEGIN--cut here/d' "$@" | uudecode cat /tmp/mrhuuj$$ | grep begin | sed 's/begin [0-9]* \([a-zA-Z0-9]*\)\..*/\1/' |\ sed -e 's/\(.*\)/\1\.hed/' >/tmp/mrhuuj$$.name cat /tmp/mrhuuj$$ | sed '/BEGIN--cut here/,$d' >`cat /tmp/mrhuuj$$.name` rm /tmp/mrhuuj$$ /tmp/mrhuuj$$.name This produces a pair of files: progname.hed and progname.zoo. The .hed file contains the text at the head of the first part of the posting, and the .zoo file is ready for transfer to a PC for unarchiving. If you read your news on a Unix machine, this should work for you, if not you might be able to get it to work with the Unix-alike tools available for PCs, but it may not be too easy. To use the above with nn, you type 'S' followed by '|uujoin', and then the letters of the postings (in the correct order!). I hope this is of use to someone, Mark PS If Ian Phillips is reading this - yes, I do remember you wrote the orignial version. I just tweaked it to produce the .hed files! -- ---------------- Eml: mrh@camcon.co.uk or mrh@camcon.uucp | Mark Hughes | Tel: +44 (0) 223 420024 Cambridge Consultants Ltd. |(Compware & CCL)| Fax: +44 (0) 223 423373 The Science Park, Milton Road, ---------------- Tlx: 81481 (CCL G) Cambridge, UK. (Me, an opinion?)
rzi@philpav.UUCP (Roman Zielinski) (07/19/90)
In article <3994@trantor.harris-atd.com>, sonny@charybdis.harris-atd.com (Bob Davis) writes: > In article <5213@castle.ed.ac.uk> elee24@castle.ed.ac.uk (H Bruce) writes: > >Does anyone have an automated way of extracting programs from the postings in > >comp.binaries.ibm.pc ? > massuud > > which I have aliased to: > > massuud: aliased to cat * | sed /^END/,/^BEGIN/d | uudecode > Yes, it's fine but what about the posting garbage in the beginning and at the end of the messages? The following command string removes also text up to the first BEGIN and after END cat * | sed /^END/,/^BEGIN/d | sed 1,/^BEGIN/d | sed /^END/,\$\d | uudecode (/^END/,$d must be spelled /^END/,\$\d to avoid shell interpretation of $d) R. +---------------------------------+-------------------------------------------+ ! Roman M. Zielinski ! + + + + + + + + + + + + + + + + + + + + + ! ! Philips Tele & Data System AB +-------------------------------------------+ ! S-115 84 Stockholm, Sweden ! OS/2? Que? ! ! tel +46 8 782 1373 ! PS/2? Que? ! +---------------------------------+-------------------------------------------+ ! NET ADDR: uunet!mcsun!sunic!philpav!rzi ! +---------------------------------+-------------------------------------------+
nacer@hpmcaa.mcm.hp.com (Abdenacer Moussaoui) (07/19/90)
>> Bob Davis writes: >..... deleted .... >which I have aliased to: > >massuud: aliased to cat * | sed /^END/,/^BEGIN/d | uudecode > >The files are miraculously concatenated together, everything NOT between >the BEGIN and END lines of each posting is discarded; and finally, >the residue is UUDECODED. > > > Doesn't this assume that you save each posting in a separate files making sure you name the files are named eg. p01 p02 ... p19 instead of p1 p2 ... p19 so that they are correctly sorted when unix expand the wild character above? It is much easier task to save the postings (especially when they are in the correct order) to the same file and then run the script above on that file. I usually use the sequence (in notes) s f <return> <return> repeatedly and just make sure the postings get concatenated in the correct order. BTW. why are parts 2...etc of a postings posted as responses? I guess they would not arrive in the same order?
harry@neuron1.Jpl.Nasa.Gov (Harry Langenbacher) (07/20/90)
In article <5213@castle.ed.ac.uk> elee24@castle.ed.ac.uk (H Bruce) writes: >Does anyone have an automated way of extracting programs from the postings in >comp.binaries.ibm.pc ? ----------pieces of old articles---------------- >Article 1911 of alt.sources: >From: csu@alembic.acs.com (Dave Mack) >Newsgroups: alt.sex.pictures,comp.lang.perl,alt.sources,alt.sex.graphics >Subject: uumerge.perl - merge and uudecode split uuencoded files >Date: 9 Jun 90 17:43:03 GMT >Sender: csu@alembic.acs.com (Dave Mack) a perl script called uumerge, which takes a collection of split uuencoded files, strips off the e-mail garbage, signatures and other drivel, and pipes the resulting data stream through uudecode. The files must be in the correct order on the command line, must be uuencoded using the "M" default (61 characters per line), and must form a complete set - the first file must contain the "begin" line, the last file must contain the "end" line, and must form only one uuencoded file. Please read the comments at the beginning of the script before using. Example: I saved the three-part uuencoded gif posting of glynn in alt.sex.pictures as glynn.gif.uu.part[1-3]. The following command produced a useable glynn.gif file: uumerge glynn.gif.uu.* The main advantage of this script over the others that have been posted to alt.sex.pictures so far is that it doesn't care how the poster delimited the start and end of the uuencoded data - it doesn't look for specially formatted "cut" lines. It relies on the uuencoded data being in a specific form, which every uuencoded posting to asp has had so far. I'd appreciate reports of corrections and improvements. I leave it to someone else to write the sh/sed/awk version of this. -- Dave Mack csu@alembic.ACS.COM >Article 1913 of alt.sources: >From: csu@alembic.acs.com (Dave Mack) >Newsgroups: alt.sex.pictures,alt.sources,comp.lang.perl >Subject: uumerge Patch 1 >Date: 11 Jun 90 06:31:58 GMT Apparently some versions of uudecode are too stupid to ignore anything in a file preceding a "begin" line, so when a single file is fed to uumerge, it will fail. This patch corrects the problem. Feed this article to patch in the appropriate directory or make the changes by hand. patch -d <directory-where-uumerge-lives> < patch1 ----------end of pieces of old articles---------------- original script and patch deleted. - Harry Langenbacher 818-354-9513 harry%neuron1@jpl-mil.jpl.nasa.gov harry@neuron1.jpl.nasa.gov 128.149.12.7
gharring@enint.Wichita.NCR.COM (Gary Harrington) (07/20/90)
>>Does anyone have an automated way of extracting programs from the postings in > . . . the following alias has worked to perfection for me. I have only to >copy all parts of a posting: say > POST1, POST2, POST3 >to a given directory in which NO OTHER FILES RESIDE and then, in >that directory, to issue the command: > massuud >which I have aliased to: >massuud: aliased to cat * | sed /^END/,/^BEGIN/d | uudecode \\\\\\\\\__________________________________________________________///////// ///////// \\\\\\\\\ change this alias to: cat $* | sed '/^END/,/^BEGIN/d' | uudecode and then the postings don't have to be in a directory by themselves. You would concatenate and uudecode them with this command: massuud POST* I call my script file 'catuudec', which seems easier to remember than 'massuud'. --- Gary.Harrington@Wichita.NCR.COM
sonny@charybdis.harris-atd.com (Bob Davis) (07/21/90)
In article <397@philpav.UUCP> rzi@philpav.UUCP (Roman Zielinski) writes: >In article <3994@trantor.harris-atd.com>, sonny@charybdis.harris-atd.com (Bob Davis) writes: >> In article <5213@castle.ed.ac.uk> elee24@castle.ed.ac.uk (H Bruce) writes: >> >Does anyone have an automated way of extracting programs from the postings in >> massuud: aliased to cat * | sed /^END/,/^BEGIN/d | uudecode > Yes, it's fine but what about the posting garbage in the > beginning and at the end of the messages? PERHAPS your uudecode works differently, but mine strips the stuff before the first BEGIN as well as after the last END (which is all the header and trailer stuff which remains after the script above is run). SO, this causes my uudecode no problem. Therefore, I did not have to include the additional features incorporated into your suggested script (shown below). Is this not the typical way that uudecode works? YOUR SCRIPT: > The following command string removes also text up to the first > BEGIN and after END > >cat * | sed /^END/,/^BEGIN/d | sed 1,/^BEGIN/d | sed /^END/,\$\d | uudecode -Peace... ______________________________________________________________________________ Bob Davis \\ INTERNET : sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\ UUCP : ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\ AETHER : K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\ VOICE : (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\ FAX : (407) 729-2537 | FOR MYSELF. |_________|
sonny@charybdis.harris-atd.com (Bob Davis) (07/21/90)
In article <140012@hpmcaa.mcm.hp.com> nacer@hpmcaa.mcm.hp.com (Abdenacer Moussaoui) writes: >>> Bob Davis writes: >>..... deleted .... >>which I have aliased to: >> >>massuud: aliased to cat * | sed /^END/,/^BEGIN/d | uudecode >> >>The files are miraculously concatenated together, everything NOT between >>the BEGIN and END lines of each posting is discarded; and finally, >>the residue is UUDECODED. > >Doesn't this assume that you save each posting in a separate files >making sure you name the files are named eg. p01 p02 ... p19 instead >of p1 p2 ... p19 so that they are correctly sorted when unix expand >the wild character above? * * * YES, THIS SCRIPT DOES ASSUME THIS. Thus for postings of more than 9 parts, this can cause a problem unless the parts are named so as to be alphabetically sorted properly. (Don't the postings having more than 9 parts start at PART01, anyway, so that the right thing happens in the wild-card expansion? I can't remember.) ______________________________________________________________________________ Bob Davis \\ INTERNET : sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\ UUCP : ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\ AETHER : K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\ VOICE : (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\ FAX : (407) 729-2537 | FOR MYSELF. |_________|
brad@looking.on.ca (Brad Templeton) (07/23/90)
If the moderator of this group ever decides to use ABE encodings, even ABE in 'uuencode' format, then you just take the various parts, in any order, with imbedded repostings and random articles, and say dabe *, and you get the result. No fuss or muss. That was the whole point of the program. But the moderator had decided not to use ABE, I was never told why. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
bg11+@andrew.cmu.edu (Brian E. Gallew) (07/23/90)
Actually, uudecode on the DOS side will uudecode files in the correct order as long as they are named correctly. The only caveat is that NL's must be converted to CR/LF pairs.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (07/23/90)
In article <1990Jul22.200236.26809@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: | But the moderator had decided not to use ABE, I was never told why. The decision on archiver and encoder was made by vote of the readers, not by the moderator. The moderator didn't decide to override that because: 1. It doesn't help the moderator 2. it means the moderator has to distribute additional software, instead of using something which is part of news. 3. It means users have to get more software, and people at site where you can't compile stuff on the UNIX box will be cut off. 4. it means c.b.i.p would be diferent from the other groups. 5. It means the moderator has to rewrite 30-something admin scripts, or at least check that each one does not use coding in any way. Right now the group is back on an even keel and we're getting about 2MB a week of stuff out. As the readers if they want to convert to a new system to avoid having to save their postings in order. As about rewriting the starter kit. I am totally against changing the archiver or the encoder, because it has a relatively high cost and low return. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
storm@texas.dk (Kim F. Storm) (07/24/90)
>elee24@castle.ed.ac.uk (H Bruce) writes: >>Does anyone have an automated way of extracting programs from the postings in >>comp.binaries.ibm.pc ? mrh@camcon.co.uk (Mark Hughes) writes: >I use the following Unix shell script with the newsreader nn (which orders >the postings for me): I don't understand why you need to pipe from nn to a shell script - maybe you are using a really old nn version? In release 6.4 of nn, you simply select *all* the articles you want to decode (they can be for multiple multi-part packages), on all menu pages. Then you enter :decode and the name of a directory where you want the decoded files to be placed. nn will then skip garbage from the header and tail (headers are stored in Decode.Headers), concatenate the uuencoded data, and perform the decoding storing the result in the file names specified on the "begin" line. To decode all articles, simply enter: =.(return) selects all articles :decode(return) call the decoder ~/pc-sw the directory where the decoded file should go. + decode all selected articles Thats it! You can even define it in a macro and invoke it with a single key-stroke! So to decode everything, just hit ^D (or F3 or whatever you bind it to). -- Kim F. Storm <storm@texas.dk> No news is good news, Texas Instruments A/S, Denmark but nn is better!
boylanr@silver.ucs.indiana.edu (ross boylan) (07/24/90)
Check if your newsreader has facilities to extract files automatically. I use nn, and it has a :decode command which seems to work fine (I just used it for the first time yesterday). First, I selected all messages in a group (in the selection menu), then said :decode. It asked some questions about where to put it and what files to use (* = all selected). I don't know if readers other than nn can do this sort of thing. nn also has the :shar command for shar files.
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (07/27/90)
In <1990Jul22.200236.26809@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >But the moderator had decided not to use ABE, I was never told why. Abe was posted to comp.binaries.ibm.pc and comp.sources.misc around mid-1989 while I was still moderator. At that time my comments that accompanied the binary posting (paraphrased) were that Abe could be very useful, but whether it was used for Usenet binary postings would depend on user feedback. There was absolutely no user feedback; probably most users decided not to worry about it since it wasn't being widely used (the old chicken-and-egg problem.) In its fully uuencode-compatible mode, abe has only a slight advantage. In its uuencode-incompatible mode, abe has distinct advantages, but it wasn't immediately clear to me at that time if those advantages outweighed the possible problems caused by having to retrain users. The *main* advantage of abe was independence from ordering of parts. Another advantage, human-readability of text, probably isn't a real advantage, since it's very unlikely that binary postings will appear in any other than compressed-archived format. I think some moderator of some binaries newsgroup (Bill?) should give abe a try. In the long run, if users can be easily retrained, abe will be an improvement. I think it would be a great idea if those who have tried abe were to post their opinions about it versus uuencoding. -- Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
roy@cs.umn.edu (Roy M. Silvernail) (07/27/90)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > Abe was posted to comp.binaries.ibm.pc and comp.sources.misc around > mid-1989 while I was still moderator. At that time my comments that > accompanied the binary posting (paraphrased) were that Abe could be > very useful, but whether it was used for Usenet binary postings would > depend on user feedback. > > There was absolutely no user feedback; I recall the posting, and I also recall contributing just a bit of feedback. Brad posted ABE in its ABE-encoded form, and included the 'tiny-DABE' decoder in the header. The stated intent was to demonstrate the usefulness of the package. As the thread dealt with a packaging scheme for c.b.i.p, I pulled the posts onto my PC and attempted to compile tiny-DABE under Turbo C 2.0, without success. The resulting .exe, while compiled without error, was non-functional. The code, however, compiled and ran without incident on a Unix box. Since we _were_ looking for a scheme to be directed at PC's, I felt (and posted) that ABE might not be the best choice. Clearly, if binaries of ABE were distributed widely, the situation could change. But I had found ABE to be less than the panacea it was described as. > I think some moderator of some binaries newsgroup (Bill?) should give > abe a try. In the long run, if users can be easily retrained, abe will > be an improvement. > > I think it would be a great idea if those who have tried abe were to > post their opinions about it versus uuencoding. Now that you've reminded me of it, I'll be hauling the ABE sources out and trying to build them. (hopefully with more success than my last attempt) Once that's done, I'll wring it out a bit and post my findings. -- Roy M. Silvernail | #include <stdio.h> | Does virtual now available at: | main(){ | reality need cybrspc!roy@cs.umn.edu | float x=1; | swap space? (cyberspace... be here!)| printf("Just my $%.2f.\n",x/50);} | -- me
NU013809@NDSUVM1.BITNET (Greg Wettstein) (07/27/90)
I watched with interest when Brad posted the ABE and DABE sources to c.b.i.p.
to see what would happen. I am sure that if Brad had his druthers he would
probably want to try and do the whole thing again. I think it was a mistake
to post the sources in a format which differed from the standard currently
being used. I think the users and especially the moderator deserve the
consideration of using the agreed upon standard.
Even though Brad may have erred in his posting technique I think we as a group
are in err if we do not give his new encoding techniques serious consideration.
UUencode and UUdecode are indeed standards and are in widespread use, they
also appear to be a consistent source of problems for people trying to decode
binary postings. They function very well when used properly but in my opinion
they were not designed for the type of application environment we find
ourselves in.
Brad gave some very careful consideration to the problems that the net faces
when he designed his en{de}coding utilities. ABE and DABE are designed from
the ground up to deal with multi-part postings, header and trailer information
and the perennial difficulty of ASCII to EBCDIC conversion. The addition of
these functionalities alone should provide sufficient merit for giving his
utilities consideration. Beyond this ABE and DABE provide error checking,
splitting of large postings, universal naming and optimization of the
encoding technique to generate the smallest encoded files. These are all
enhancements which should make life easier for people who have to deal with
encoded postings.
I grabbed the sources from the net and had them up and running under both
MS-DOS and UNIX with very few problems. After experimenting with them I
began testing them on a few selected users within our own mail/communication
domain. Both my beta users and myself have experienced few problems with the
utilities and I personally find it difficult to go back to uuen{de}code
formats.
I have no connection or affiliation with Brad. I have never spoken with him,
never received a piece of mail from him and wouldn't know him if we walked
by me on the street. I also believe that he made a mistake when he first
introduced his utilities to the USENET community. This notwithstanding I
also believe that his utilities have the ability to make a significant
contribution to the way we conduct business in this group.
I have watched, with interest, this newgroup for a long time. I have seen
it move from being close to extinction due to lack of control and
organization to a clean, well run group which is moving an awful lot of
productive volume to its users. This group has strived for portability
by using zoo as its compression format, has developed tools such as brik
to aids its members and strives through repeated postings of starter kits
to educate its new users and to keep old users current.
We now have an opportunity to consider another advancement. I believe that
anyone who looks very carefully at the functionality of ABE and DABE will
acknowledge that it possesses some significant advantages over our previous
uuen{de}code technology. Many of us who belong to this group are trained
with a technical/scientific background. The individual who trained me always
stressed the importance of being introspective with regard to technology and
to always being asking the question, 'Am I using using the best, most efficient
methodology currently available?'. If, as a group, we ask ourselves that
question it will be a moot point whether or not we re-examine Brad's utilities.
I am sure that this will generate some discussion. We are settling into our
new operation but I do not have news running within the Center's domain. If
anyone would like to follow up via e-mail please use the address in my
signature. It will save me from having to climb on the mainframe to handle
my mail. I read the group every morning so I will catch anything that gets
posted as discussion. Thanks and I will be interested to see what happens.
As always,
Dr. G.W. Wettstein
Roger Maris Cancer Center Computing Facility
UUCP: uunet!plains!wind!greg
INTERNET: greg%wind.uucp@plains.nodak.edu
Phone: 701-234-2833
`The truest mark of a man's wisdom is his ability to listen to other men
expound their wisdom.'bxw@ccadfa.adfa.oz.au (Brad Willcott) (07/28/90)
elee24@castle.ed.ac.uk (H Bruce) writes: >Does anyone have an automated way of extracting programs from the postings in >comp.binaries.ibm.pc ? >Ideally this would order the postings correctly (they sometimes appear in the >wrong order) and extract and concatenate the uuencoded text. You could try 'nn' on a Unix OS. It is what I use, and it is quite easy to decode/unshar postings. -- Brad Willcott, ACSnet: bxw@ccadfa.cc.adfa.oz Computing Services, Internet: bxw@ccadfa.cc.adfa.oz.au Australian Defence Force Academy, UUCP:!uunet!munnari.oz.au!ccadfa.oz!bxw Northcott Dr. Campbell ACT Australia 2600 +61 6 268 8584 +61 6 268 8150 (Fax)
readdm@walt.cc.utexas.edu (David M. Read) (07/29/90)
This exact discussion has come up on several other groups to which I
subscribe; whether or not to scrap the uuencode standard and move
on to something better (with concommitant headaches as everyone
scrambles to get the new code), or just to stick with the one eveybody's
alread got?
Well, I don't think there's any need to scrap uuencode...I have recently
written a new version of uuencode that uses the old standard, but
automatically handles multi-part encodes and decodes, splitting large
files and adding "cut here" lines in the encode case, and skipping
over headers & trailers in the decode case. It's menu-driven and
supports a command-line mode, comes with (simplistic) on-line help
and it's free to anyone who wants it.
If you'd like a copy of the source code and/or the MS-DOS executable,
send me a message at read@lampf.lanl.gov and tell me which you want
(also UNIX and VMS versions will be available shortly), and I'll send
it out as fast as I can.
So far I have gotten over 100 requests for it from the readers of
alt.sex.pictures, and no-one has expressed anything but general
satisfaction.
The advantage to this, of course, is that it allows you to have the
ease-of-use you want without forcing a change of standards...so the
people stuck in the dark ages can remain there happily.
Anyway, just tryin' to help...
-Dave | LAMPF and UT don't believe that
Dave Read: read@lampf.lanl.gov | their people have opinions. Who
read@physics.utexas.edu | am I to disillusion them?
readdm@ccwf.cc.utexas.edu | #include <cutepicture.h> wales@valeria.cs.ucla.edu (Rich Wales) (07/29/90)
In article <34590@ut-emx.UUCP> readdm@walt.cc.utexas.edu (David M. Read)
discusses a new version of "uuencode" he has written, which is backwards
compatible with the original "uuencode", but which also handles multi-
part files. He feels there is no need to scrap "uuencode".
I must disagree.
One big problem with "uuencode" is that lots of people who read this and
similar newsgroups get their feeds through machines which use the EBCDIC
(IBM) character code. Translation between ASCII and EBCDIC, in the real
world, frequently results in one-way munging of several of the special
characters used by "uuencode" -- such as the square brackets, the curly
braces, and the backslash. The result is that a "uuencode" file, once
having gone through a defective ASCII/EBCDIC translation, is corrupted
beyond repair.
It isn't just a question of undoing the bad translation: if several
different characters all get changed into question marks, you are stuck.
Getting all affected machines to "fix" their ASCII/EBCDIC translation
tables is a gargantuan task that has essentially been given up as hope-
less.
If we aren't willing to use something as completely different as Brad
Templeton's ABE, we should at least change to "xxencode". "xxencode" is
precisely the same as "uuencode", except that the 64 characters used to
encode the file are taken from a set that is known to be immune to
ASCII/EBCDIC mangling (specifically, "xxencode" uses upper and lower
case letters, digits, and the plus and minus signs).
It would be trivial to add an option to a "uuencode" clone to let it
support "xxencode" as well -- since, as I said, the file structure is
utterly identical except for the character code.
--
-- Rich Wales <wales@CS.UCLA.EDU> // UCLA Computer Science Department
3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683
"Indeed! Twenty-four is the gateway to heroic salvation."brad@looking.on.ca (Brad Templeton) (07/30/90)
Actually, there are few differences in the advantages between ABE's uuencode mode and the ABE encoding modes. Those are: a) The human readable binaries -- this is useless on compressed binaries. However, there is a strong argument that binaries should not be compressed. (The transmission schemes are already compressed and this wastes time) There is a counter argument however, wrt disk space in the spools. b) Smaller encodings -- they are actually about the same size on compressed binaries. c) The ABE2 character set is designed to be bitnet-proof. So is the xxencode character set. The UUENCODE set is not as bitnet-proof. The xxencode set could be added, but that defeats the universality of the UUENCODE character set. The multi-part encoding redundancy, the CRC32s and the other fields all apply to the uuencode version, even if they are ignored by typical uudecode programs. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
frisk@rhi.hi.is (Fridrik Skulason) (07/30/90)
In article <34590@ut-emx.UUCP> readdm@walt.cc.utexas.edu (David M. Read) writes: >Well, I don't think there's any need to scrap uuencode...I have recently >written a new version of uuencode that uses the old standard, but >automatically handles multi-part encodes and decodes, splitting large >files and adding "cut here" lines in the encode case, and skipping >over headers & trailers in the decode case. Well, this is useless to me, as it does not solve the biggest problem with UUencode - regarding file transfers to/from BITNET sites. I regularly receive binary files (encrypted viruses) from BITNET sites, and experience has shown that UUencoded binaries regularly get scrambled. My solution has been to use xxencode instead, which is only minimally different from uuencode, but does not have this problem. -frisk -- Fridrik Skulason University of Iceland | Technical Editor of the Virus Bulletin (UK) | Reserved for future expansion E-Mail: frisk@rhi.hi.is Fax: 354-1-28801 |
Bob.Davis@gisatl.FIDONET.ORG (Bob Davis) (09/01/90)
-- ----------------------------------------------------------------------------- Bob Davis - via FidoNet node 1:133/411 UUCP: galbp!gisatl!Bob.Davis INTERNET: Bob.Davis@gisatl.FIDONET.ORG