💾 Archived View for spam.works › mirrors › textfiles › computers › alt-bin.txt captured on 2023-12-28 at 17:12:01.
⬅️ Previous capture (2023-06-14)
-=-=-=-=-=-=-
Notes on UUDECODEing .GIF pics etc.
This file is intended to be a general introduction to the group
alt.binaries.pictures, answering some common questions concerning pictures
posted here, namely how to decode and view them. It is not, of
course, possible to cover everything, but I will try to to get as much
as I can into this file. If you feel something important has been
omitted and you know the subject well, please write me so I can
include the info for future releases. I can be contacted via
internet at readdm@ccwf.cc.utexas.edu.
Before you miss an important detail contained in this file, let me
"pre-repeat" that I have tried to make *all* programs mentioned in
this document available for anonymous ftp at bongo.cc.utexas.edu
(128.83.186.13), in the gifstuff directory. If you think I've omitted
something important in the viewers-only archive, feel free to let me
know. Also: there are NO GIF files of any kind at this site! Save
your time and don't bother looking for them!
Ok...on to the real reason you're reading this document...
TABLE OF CONTENTS
I. DOWNLOADING AND DECODING FILES
II. .GIF FILES AND .GIF VIEWERS
III. .GL FILES
IV. OTHER PICTURE TYPES
V. ENCODING AND UPLOADING FILES
VI. ALTERNATE SOURCES FOR PICTURES
VII. A.B.P. and A.B.P.D.
VIII. COMMON PROBLEMS
IX. APPENDICES: AWK, SED, & PERL SCRIPTS
I. DOWNLOADING AND DECODING FILES
By far the most common method of posting files to alt.binaries.pictures is
the UUENCODE standard. This program, shipped standard with most
implementations of UNIX, converts binary files into plain-text ASCII
files which can be handled by the mail system. You will need a
version of UUDECODE before anything else in order to view anything
downloaded from the net. If your system does not have a version of
UUDECODE available, you can get one via anonymous ftp from
bongo.cc.utexas.edu (128.83.186.13), in the gifstuff/uuxfer directory.
The first step is to save the file you want to view...in most versions
of the newsreader, this is done by pressing s followed immediately (no
spaces) [NOTE: my rn will allow spaces, though-SQ] by a file name.
You will usually be asked if you want to save it in mailbox format;
you should answer 'n'.
In the case of a single-part file, you can now uudecode the file,
which will create whatever output file is encoded. You can usually
tell if it's a single-part file by looking on the subject line;
standard nettiquette is to make somthing like (03/06) part of the
subjet line, which indicates you're on part 3 of a 6-part file. If no
numbers are there, you can usually assume it is a 1-part file. If
not, feel free to write the poster (directly...please don't waste
bandwidth by posting) and request that he/she put this info in the
subject line. Be nice about it!
For multi-part files, life is a little more difficult. If all you
have is a standard UUDECODE program, you will need to trim the headers
and trailers from all of the parts and concatenate the resulting files
together to make one big file, and then run that through UUDECODE.
Use your favorite text editor to strip the headers & trailers of each
file. Then (on UNIX systems) use
cat part1 part2 part3 ... partN | uudecode
to concatenate them and pipe them through uudecode.
If you downloaded the files to an MS-DOS system before concatenating
them, use
copy part1 + part2 + part3 + ... + partN file
to concatenate them.
There are several versions of UUDECODE out there that will do all of
this for you, including UUEXE (an MS-DOS program written by Richard
Marks) and my own UUXFER program.
Several people have written scripts in AWK, SED, or PERL which will strip
headers & trailers, concatenate the results and pipe them through
UUDECODE. See section IX. (Appendix) if you want to run one of these.
If you're going to download it to a home machine, or move it around a
network, remember that most outputs are going to be BINARY files, so
set your transfer protocol accordingly.
II. .GIF FILES AND GIF VIEWERS
Ok. Now you've got this great GIF file from downloading it and
running it through UUDECODE. What is it, and what do you do with it?
GIF stands for Graphic Interchange Format, and is a standard format
for images that was developed by Compuserve to be a device-independent
method of storing pictures. It includes Lempel-Ziv-Welch (LZW)
compression, which makes the files fairly small.
You will need a GIF viewer in order to view the file. On X-Windows
workstations the program you need is called xloadimage. If your
system does not have xloadimage, you can get it via anonymous ftp
from bongo.cc.utexas.edu in the gifstuff/xwindows/xloadimage directory.
[NOTE: There are some other good ones there too, like xv and xshowgif.-SQ]
On the Macintosh, a good one is QuickGIF, but it only runs on color
Macs. If you have a monochrome Mac, you can use VisionLab.
On MS-DOS systems, I personally use VPIC, but there exist
others, including CSHOW. A nice bonus to using CSHOW is that it can
also view several other common picture formats, including MacPAINT
images. Amiga users tell me that VirtGIF will display .GIF files
directly, but that Hamsharp or GIFMachine will convert .GIF
files to other formats, the principle benefit being that the other
formats allow more than 256 colors to be displayed simultaneously.
Other machines: On Sun workstations running SunView, Alan Sparks has
made his 'artshow' program available, at the same archive mentioned
earlier, at ix1.cc.utexas.edu and bongo at the same address.
For the Atari ST, there exist several shareware or PD programs, including
BGIF & GIFSPEC, which will convert the GIF files to the Spectrum file type,
which can then be viewed with other software (sorry, I don't know what it's
called). Finally, Apple ][+/e/c types are advised to use IIGIF to view gif
files on these computers, while the advice from a ][GS user is to use
SHRConvert.
I have tried to make all of the above-mentioned GIF viewers available
from bongo.cc.utexas.edu, in the gifstuff directory. Hunt through the
0filelist file to see if something you need is available.
Other systems have other viewers. Consult your sysytem administrator
or a local users group for your machine before you post to the asking
if there is a GIF viewer for your specific machine.
III. .GL FILES
Commonly people post files to the net with a .GL extension. These
files are actually animated picture-shows that can be viewed on IBM-PC
machines with the GRASPRT program. The GRASP (GRAphics System for
Professionals) system was developed by Paul Mace as a PAY-WARE system
for transmitting these animated files. The GRASPRT program (public
domain, I believe) is a run-time version for viewing the files.
Unfortunately, GRASPRT exists only for the PC-Clone family. Recently
some wonderful net-people have written an X windows-based .GL viewer
called xgl (there is also another called xgrasp, but I know little
about it). The source is available from export.lcs.mit.edu...look
in the directory where they keep contributed X code. I will also
endeavor to maintain a copy on bongo.cc.utexas.edu, but I can't promise
that it will be up-to-date. Recently an Amiga version was written...
you can find it in the amiga directory at bongo.
There is another twist to GRASPRT. An older version admitted only CGA
monitors, but a newer one allows VGA as well. Unfortunately, the
older version doesn't even *recognize* the VGA standard, while the
newer version (which, BTW, is *much* faster than the old one) will not
let you display the VGA GRASP files on a CGA or EGA monitor. Unlike
the .GIF standard, .GL files are not resoultion-independent!
Anyway, if you have a system other than a PC-Clone, an X system, or an
Amiga, I'm afraid you may be out of luck. Sorry!
Usually, .GL files are huge, so people often compress them with one of
several popular compression/archiving packages. Perhaps the most
common is the PC family's PKZIP package. If a .GL file is posted with
a .ZIP extension, you know it's been ZIP'ed. Similarly, if it has a
.Z extension, it's been compressed with the UNIX `compress' utility.
If you encounter a file which has been ZIPed, and you have a PC, you
should go find a copy of PKUNZIP (simtel has one). If you *don't*
have a PC, you can get C source code for an UNZIPer from simtel, in
pd1:<unix-c.file-mgmt> as unzip.tar-z (you'll have to decompress this
with the UNIX compress utility).
If the file has been compressed with the UNIX compress utility, and
you're on a UNIX box, clearly you have no problem. If, on the other
hand, you're on some other box, you'll need a de-compressor. You can
find an msdos version of unix compress can be obtained from simtel in
pd1:<msdos.sq-usq> or wuarchive.wustl.edu in /mirrors/msdos/sq-usq as the
file comp430d.zip.
IV. OTHER PICTURE TYPES
There are other types of single-picture files posted to the net,
although they are not as common as the .GIF files. I suppose that the
next most common type of picture posted is the MacPaint picture.
These pictures, once decoded, are viewable on the Macintosh with the
standard MacPaint program. On the PC-Clone family, the pictures are
viewable with (among other progams) CSHOW. Other than the difference
in the viewing software, the downloading/decoding and encoding/uploading
procedures are identical as for other types of pictures.
Another common form for pictures to take is the .IFF file, which is a
standard for pictures on the Amiga. I do not know of many programs for
computers other than the Amiga which allow viewing of these files, but
there exist some programs on the Amiga which will convert .IFF files
to .GIF files so the rest of us can see them. It has been pointed out
to me that DeluxePaint on the IBM-PC family will work with .IFF files,
but I have not verified this.
Occasionally people get into an argument about which standard is best.
I think the answer is: WHO CARES?!? The only thing I have to say
about this matter is that almost every machine under the sun already
has a program written for it to view .GIF files, and if yours doesn't,
shareware or PD source code is available almost everywhere.
V. ENCODING AND UPLOADING FILES
A common question that is asked is this one: what should I post to the
net? The basic answer is: anything you'd like to see here yourself!
Before I get into the nitty-gritty of how to post, I should say
a few things about the loose etiquette of posting.
[NOTE: this paragraph is more specific to alt.sex.pictures but still relevant]
The first thing is this: it's probably best to restrict yourself to
one or two images per day. I know you've got 600 MB of XXX-rated GIF
files of your girlfriend engaged in various acts with yourself and a
host of small furry animals that you're dying to distribute all over
the world. However, the net gets severely loaded down by these images,
since they are typically 100 - 300 Kb each. When you post ten of
them at once, lots of people will be frantically downloading them,
which shows up in the weekly Arbitron ratings when alt.sex.pictures
accounts for something like 50% of the entire net traffic, and 75% of
the alt.* traffic. We need to be self-policing if a.s.p is going to
avoid being axed by nervous sysadmins.
Second, be sure to give subject lines that are informative, like:
CRASH&BURN.GIF: Plane crash at an air show, 800x600x256 (02/08)
Notice that it includes everything: the file name, a short
description, the resolution, and what part of how many this one is.
If you insist on leaving everything *else* out, at least say which
part it is!
Third, in the actual message you're posting, be sure to give at least
a brief description of what's in it, like:
CRASH&BURN.GIF 800x600x256 (in 8 parts)
This is 15th in the series of this plane crash at the Beruit Air Show
taken at every single conveivable angle. This one was taken from a
photograph by a guy who happened to be standing directly under the
plane as it came down. Pulitzer Prize material. At least the camera
was saved.
Also, checksums are nice, for people with access to sum programs. It
helps people indentify erroneous transmissions. Usually people say
things like
Checksums: (obtained with 4.2 BSD 'sum' or SysV 'sum -r')
between 'CUT HERE lines':
part 1: 76663 9082
part 2: 78973 1234
etc...
Finally, if you got the file from some FTP site that was announced
over the net, don't bother posting it. 5-to-1 odds say that everyone
and his dog already have it, and we *really* need to be careful about
wasting bandwidth! If you're unsure of whether there's any interest
in it, just post a short message saying: "I have this file. Mail me
if you want a copy." If 500 people say they want one, post it...if
only one bozo from outer mongolia wants it, it's a sure bet that the
picture has already made the rounds!
Ok...on to the how-to's of posting.
First things first: if you have a GIF file, don't bother trying to
run some compression routine on it...it *won't* work. LZW compression
(the kind used in GIF files) is a very efficient compression scheme,
and happens to be the one used in many common compression routines
(including the standard UNIX `compress' utility!). If you try to compress
a GIF file, it will usually just end up getting bigger.
Ok. You need to UUENCODE the file. Find an encoder and encode it!
If the output file is particularly large (i.e. more than 60 kB), it
would be wise to split up the encoded file into smaller parts (< 60 kB)
and then post those. You can split the file with a text editor if you
like, or...use Richard Marks' UUEXE or my UUXFER programs, which will
do that for you.
If you do post a multi-part file, be sure to add lines before and
after the data that say 'CUT HERE' so that people trimming the headers
& trailers by hand know where to cut. A recent addition to the
etiquette also has you make the lines say 'BEGIN-----Cut Here' and
'END-----Cut Here' at the obvious locations, so that simple AWK and
PERL scripts can handle multi-part files. Another nice thing to do is
to put the part (02/06) numbers in each file. Again, the afore-
mentioned 'super' uuencode programs will do most of this for you. It
is important to make the "Cut Here" parts in mixed-case or lower-case
letters; some decoders detect data based on the presence of characters
which belong in the normal uuencoding character set, and they will
choke on lines which are all upper-case, since these lines contain
only characters which belong in the set. If you mix the cases, these
decoders will do fine...Remember (if you add "BEGIN" and "END"
keywords) to make "BEGIN" and "END" all caps so exsting scripts won't
miss them, and so uudecoders won't choke on them.
Now post the files...and remember to include the neat info mentioned
earlier, like subject lines that mean something, descriptions,
checksums, etc... One thing that has been pointed out to me recently
is that certain newsreaders (NN, for example) sort the articles
alphabetically by title, so subject lines with part numbers get
displayed & saved in order. There is an obvious (and common) way to
torpedo this process: make subject lines which do not follow sequentially.
An example:
first article's subject: "plane crash GIF: CRASH&BURN (part 1 / 4)"
subsequent articles' subjects: "CRASH&BURN (part N / 4)"
These subject lines will not be displayed & sorted correctly by NN.
However, if you change the arrangement a little, like this:
first article's subject: "CRASH&BURN (part 1/4) plane crash GIF"
subsequent articles' subjects: "CRASH&BURN (part N/4)"
you will please NN-users the world over.
That's about it for posting!
VI. ALTERNATE SOURCES FOR PICTURES
Alt.binaries.pictures is certainly not the only source for pictures, nor
are .GIF files the only types available (see section IV.). The most
likely place you are to find other pictures is in an archive that is
reachable via FTP. FTP stands for File Transfer Protocol, and is a
program for transmitting files over the network. To use FTP, you will
need access to a computer with the FTP program, and a network
connection.
Most ftp programs will allow you to enter something like
ftp wsmr-simtel20.army.mil
which will connect you with the mighty SIMTEL-20 archives at the White
Sands Missile Range. Occasionally, you will encounter an ftp program
that is old enough or slothful enough that it does not recognize
internet-style addresses like the one above. In that case, you'll
need to know the computer's numeric address; for SIMTEL-20
you would enter
ftp 192.88.110.20
Once you're connected, you'll have to tell the computer at the other
end that you want to log in, by entering USER (some machines save you
this step by *assuming* you want to log in. What else would you want
to do?) When you are prompted for an account name, enter
anonymous
When it asks you for a password, enter *your* internet address.
Often the machine to which you are trying to connect will be busy
(i.e. too many anonymous users), in which case the machine will inform
you of this and throw you off. Try again later.
Now you're in. What do you do? Well, you need to know where the
files are stored that you want. If you know this, just
cd directory-name
to the directory in question. Then you can do a DIR to find out
what is in it.
So you see a file called CRASH&BURN.GIF and you want it for yourself.
What do you do? Well, the first thing is to tell the computer on the
other end that you want it to transmit a binary file. On most FTP
servers, entering the magic word TENEX will do this. If the machine
doesn't recognize TENEX, try BINARY, or if all else fails, you can
enter
TYPE L 8
Be sure to do this for .GIF files or you'll get garbage when you try
to view them!
Now you're ready to grab the files you want. You have two options:
you can type
get filename
or
mget wildcard
where wildcard is any UNIX-style wildcard. MGET will get all files
that satisfy the specification.
When you're done grabbing files, type QUIT or BYE to log off the remote
machine and return to yours.
A word about anonymous FTP and .GIF files. When you log onto a remote
machine via anonymous FTP, please try to restrict yourself to no more
then ten minutes of transmission time, or about five to ten files. As
you can imagine, when people discover a new archive of .GIF files,
they are all hot to download every one they can, and often they jam up
the site for *days* You'll notice this effect the first time some
bozo announces the name of a new .GIF archive. You won't be able to
get through without persistent efforts over several hours or even a
day or two. Then the system administrators of that site notice that
they have had about $5,000 worth of anonymous FTP over the last two
days, and revoke the anonymous FTP privilege. Now every one is
screwed.
Be considerate; grab only a few files and then let someone else have a
chance. This probably won't solve the problem in the long term (still
everyone and his dog will be ftp'ing into that machine), but at least
it will spread the wealth a bit.
A raging debate erupts on alt.sex.pictures every few weeks concerning
whether to announce new anonymous FTP sites for GIF files, and the
issue has never been settled to everyone's satisfaction. Here I add
my two cents to the discussion: if you discover a site and keep the
name to yourself or pass it on to only a few friends, then the word
will spread slowly, and the site will not have to bear an instantly
heavy load. However, if you announce to the world that you have found
this site, then everyone will descend upon it like a flock of vultures
on a rotting cow, and the site will invariably remove its GIF files.
Which sounds like a better idea to you?
The other most common method for obtaining files is from an archival
file server. Most of these work in the following way: you send mail
to the server's address, with one-line commands in your message, like
help
directory \pictures\gif\family-oriented
send \pictures\gif\family-oriented\CRASH&BURN.GIF
and the requested info is sent back to you at some later time, when
the server has time to get around to it.
The first step when you discover a server system is to send a HELP
command so you can learn what the commands are for that server.
However, most servers operate with commands basically similar to those
listed above.
VII. ALT.BINARIES.PICTURES AND ALT.BINARIES.PICTURES.D
These two newsgroups work basically like the comp.binaries.ibm.pc and
c.b.i.p.d groups; one is for posting new material, and one is for
discussing posts and other issues.
The basic idea is this: if it is a picture, post it to a.b.p. If it
is *ANYTHING ELSE* ANYTHING ANYTHING ANYTHING ELSE, post it to a.b.p.d
The truth is that I feel bad about posting *THIS FILE* to a.b.p,
because it is not a picture. However, the benefits of restricting the
requests for info outweigh the detriment of breaking the until-
recently-unwritten rule.
PLEASE DO NOT POST ANYTHING TO ALT.BINARIES.PICTURES THAT IS NOT A PICTURE
OF SOME SORT!!!!
VIII. COMMON PROBLEMS
Well, you've downloaded the file, tried to view it, and got garbage.
What went wrong?
The two most likely places for something to go wrong are both in the
transmission of the file. The first is this: when you downloaded the
file to your home computer, did you remember to tell the modem-
transfer software that you're sending a binary file?
The second-most likely is that you forgot to say TENEX before you
grabbed the file via FTP.
Either of these will result in mangled files that are unviewable by
anything known to man.
Also: did you remember to trim off the header & trailer information if
you are/were using a "simple" uudecoder? The symptom of forgetting to
do this is usually a message something like "short file" from your GIF
viewer.
[NOTE: I have also seen a problem where blank lines are left between
parts (or anywhere for that matter) within the 'begin' and 'end' lines
of the uuencoded file. Uudecode will get through them fine, but some
GIF viewers will choke on the results. The only blank line I've seen
get by is the one just before the 'end' statement. Beware of taking
too much or not enough off of the headers and trailers.-SQ]
Another common problem is this one: IBM mainframes often use the
EBCDIC character set instead of the ASCII set used by everyone else.
This wouldn't be a problem except that most ASCII-EBCDIC converters
have a bug which mungs the translation of several characters,
including ^ { } and a few others. Even this wouldn't be a problem
except that the particular munging it does is to map several of these
characters onto the *same* wrong character. Ooops.
The way around this is not to use uuencode to transfer these files,
but to use xx-encode, which produces files which look almost exactly
like uu-encoded files, but they use a character set which is
IBM-proof. If you are using an IBM mainframe as your host computer
and you're having trouble decoding files, this is most likely your
problem. Solution: 1) find a kind soul who is willing to uudecode the
files, xxencode them and send them to you, 2) get the files via FTP,
which should be EBCDIC-proof, or 3) get a better computer that uses
everybody else's character set. :-)
The last and least likely problem is that some mailer somewhere
actually munged the file. It happens. Fortunately, it doesn't happen
all that often. When it does (and please check all of the other
problems *FIRST*), post to a.b.p.d and request someone to send you
their (working) copy. If enough people post requests of this sort,
eventually the original poster will usually re-post it. If you're the
only person with a problem, someone is bound to send you the file, and
you'll save the net 'hundreds if not thousands of dollars.'
IX. APPENDICES: AWK, SED, & PERL SCRIPTS
Below are the scripts mentioned in section I. I make no assurances as
to how well they work; I use one of the 'super' uudecodes instead.
Not that the SED script will not work unless people follow this recent
trend of putting 'BEGIN' and 'END' in the 'cut here' lines. The AWK &
PERL scripts will work on most files, but some uuencodes put out
nonstandard data, in which case these scripts will bomb and you'll
have to do the work by hand.
-------------------------------------------------------------------------
AWK script:
#!/bin/sh
if [ X$1 != X ] ; then cat $* ; else cat <& 0 ; fi | \
awk '/begin [0-9]/ {ok = 1}
/^Message/ {ok = 0;next}
/^M/ && (length == 61 || length == 62) {ok = 1}
/[cC]ut [hH]ere/ {ok = 0;next}
/^END-----/ {ok = 0;next}
/^Path:/ {ok = 0;next}
/^$/ {ok = 0;next}
/^-/ {ok = 0;next}
/^_/ {ok = 0;next}
{if (ok) print}
/^end/ {ok = 0}' $* | \
(cd $HOME/tmp; uudecode)
--------------------------------------------------------------------------
SED idea from Alan Sparks (asparks@viewlogic.com):
cat $* | sed '/^END/, /^BEGIN/d' | uudecode
Recall that this won't work except on files with BEGIN & END as part
of the 'CUT HERE' lines...
-------------------------------------------------------------------------
PERL script from Dave Mack (csu@alembic.acs.com):
#! /usr/local/bin/perl
#
# Combine split uuencoded files into a single data stream with
# e-mail garbage removed and pipe into uudecode. The uuencoded
# files must be in the correct order on the command line - in
# particular the first file must contain the "begin" line and
# the last file must contain the "end" line.
#
# WARNING: this code relies on uuencode putting out all lines
# of the form "M[61 ASCII characters]\n" for every line of the
# file except the last few before the "end" line. If you come
# across a uuencoded file that doesn't do this, you'll need to
# modify the code to handle it.
#
# DISCLAIMER: You use this code at your own risk. Also, don't
# take this is as a sterling example of Perl programming. Corrections
# and improvements welcome. You may do whatever you like with this
# code as long as you leave in some reminder of who the original
# culprit^H^H^H^H^H^H^Hauthor was.
#
# Usage: uumerge filename [filename...]
# Requires Perl 3.0 - my copy is at patchlevel 18
#
# Dave Mack csu@alembic.ACS.COM
#
# TODO: modify to allow more than one collection of files on
# command line.
#
# KNOWN BUGS:
#
# If some bozo puts a line beginning with "M" in the body of one
# of the intermediate/last chunks, uumerge will assume that uuencoded
# part starts there.
#
# If the last chunk only contains the last two or three lines of
# the uuencoded file (the ones that don't start with "M"), uumerge
# will die.
#
# CHANGES
#
# PATCH 1:
# It appears that some versions of uudecode are too stupid to skip
# past the lines preceding the "begin" line, so feeding a one-part
# uuencoded file to uumerge will bomb.
#
if ($#ARGV < 0 ) {
print "Usage: uumerge filename [filename...]\n";
exit 1;
}
$| = 1;
# open a pipe into uudecode
open(DECO,"|uudecode") || die "Can't pipe into uudecode\n";
# if we only have one file, pump it straight into uudecode and die
if ( $#ARGV == 0 ) {
open(FIRST,"<$ARGV[0]") || die "Can't open $ARGV[0] for input\n";
while ( <FIRST> ) {
# skip past everything before the "begin" line
next unless /^begin [0-9]/;
last;
}
die "$ARGV[0] doesn't contain \"begin\"\n" if eof(FIRST);
print DECO $_; # the begin line
while ( <FIRST> ) {
print DECO $_ unless /^end/;
if ( /^end/ ) {
print DECO $_;
last;
}
die "$ARGV[0] doesn't contain \"end\"\n" if eof(FIRST);
}
# done with file
close(FIRST);
exit 0;
}
# process the first file - make sure we have a "begin" line
open(FIRST,"<$ARGV[0]") || die "Can't open $ARGV[0] for input\n";
while ( <FIRST> ) {
# skip past everything before the "begin" line
next unless /^begin [0-9]/;
last;
}
die "First file on command line doesn't contain \"begin\"\n" if eof(FIRST);
print DECO $_; # the begin line
# the remaining "real" uuencoded lines in this file should begin with "M"
while ( <FIRST> ) {
if ( /^M/ ) {
print DECO $_;
}
else {
last;
}
}
# done with the first file
close(FIRST);
# do all except the last file
$maxindex = $#ARGV;
$curr = 1;
while ( $curr < $maxindex ) {
open(CURR,"<$ARGV[$curr]") || die "Can't open $ARGV[$curr]\n";
# skip the header junk
while ( <CURR> ) {
next unless /^$/;
last;
}
# at the body of the message - start looking for /^M/
while ( <CURR> ) {
next unless /^M/;
last;
}
die "$ARGV[$curr] isn't a uuencoded file\n" if eof(CURR);
# OK, we're at the start of the good stuff (probably)
print DECO $_;
while ( <CURR> ) {
if (/^M/) {
print DECO $_;
}
else {
last;
}
}
# done with current file
close(CURR);
$curr++;
}
# time to do the last file in the set
$curr = $maxindex;
open(CURR,"<$ARGV[$curr]") || die "Can't open $ARGV[$curr]\n";
# skip the header junk
while ( <CURR> ) {
next unless /^$/;
last;
}
# at the body of the message - start looking for /^M/
while ( <CURR> ) {
next unless /^M/;
last;
}
# OK, we're at the start of the good stuff (probably)
print DECO $_;
while ( <CURR> ) {
print DECO $_ unless /^end/;
if ( /^end/ ) {
print DECO $_;
last;
}
die "Last file on command line doesn't contain \"end\"\n" if eof(CURR);
}
# done with final file
close(CURR);
# close the pipe to uudecode and exit
close(DECO);
exit(0);
-------------------------------------------------------------------------------
That's about it for this introduction. If you have any suggestions
for things to include in future versions, don't hesitate to let me
know...
readdm@ccwf.cc.utexas.edu
--
Dave Read (readdm@ccwf.cc.utexas.edu) | In large, friendly
UT-Austin Nuclear Physics Graduate Student (Slave) | letters were the words
Sometimes I wish life were a game of Asteroids... | Don't Panic.
So I could hit the Hyperspace button. |
The Stranger ;^{)
------------
If I sound opinionated, please remember that all opinions expressed
here, though long winded, are strickly my own and are intended to
offend and/or flame no one. If I don't sound opinionated, then you
may disregard this message. "It's either sadness or euphoria."-B. Joel