💾 Archived View for spam.works › mirrors › textfiles › computers › alt-bin.txt captured on 2023-11-14 at 09:08:43.
⬅️ 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