DP Tool Club 15

home *** CD-ROM | disk | FTP | other *** search

/ DP Tool Club 15 / CD_ASCQ_15_070894.iso / vrac / uu32.zip / UU.DOC < prev

Wrap

Text File | 1994-06-19 | 61KB | 1,089 lines

UU version 3.2 -- A small, fast, and smart uudecoder for DOS Copyright (C) June 1994 -- ir.drs. Benjamin J. Walbeehm June 19, 1994 Contents: - Introduction - Quick instructions - On the uuencoding standard - Command line parameters, switches, and environment - What UU does, and does not do - UUTool-encoded files - Handling unsorted sections - Handling wildcards - Plans for the next version (3.3) of UU - Plans for the more distant future - Acknowledgements - Release history - How to get on the UU mailing list - Contacting the author If you are pressed for time, then I suggest you read "Quick instructions" now, and the rest later. Introduction ~~~~~~~~~~~~ UU is shipped in a package called UU??.ZIP, where ?? is replaced by the version number. Until further notice, whenever I have a new version of UU, I shall upload it to FTP : ftp.portal.com /pub/bryanw/pc/misc FTP : illuminati.io.com /pub/usr/zboray/coding FTP : wuarchive.wustl.edu /pub/MSDOS_UPLOADS/uucode USENET: alt.binaries.pictures.utilities Pointer messages announcing the new release will be posted to USENET: alt.binaries.misc USENET: alt.binaries.pictures.d USENET: alt.binaries.pictures.erotica USENET: alt.binaries.pictures.erotica.d USENET: alt.binaries.pictures.misc USENET: alt.binaries.pictures.supermodels USENET: alt.binaries.pictures.tasteless USENET: de.alt.binaries.pictures.d In addition to the UU??.ZIP packages, I also post UU??.EXE packages to the alt.binaries.pictures.utilities newsgroup. These are self extracting archives, which means that they unZIP themselves. Moreover, the UU??.EXE postings can even be decoded by those that do not yet have a uudecoder! If for some reason you are unable to obtain the UU package in any of the aforementioned ways, feel free to ask me to e-mail it to you. My e-mail address may be found at the end of this manual. You can also make sure that you will receive new versions of UU right into your own mailbox as soon as they are released by subscribing to the UU mailing list. See the appropriate chapter in this manual for more information. UU is a freeware program; please read the file INFO.TXT for more information on what I mean by this. If the file INFO.TXT was not included in your UU package, then you can obtain it by e-mailing (which is preferred), writing, or calling (which is least preferred) me. IN SHORT, THE ONLY THING I ASK FROM YOU WHEN YOU DECIDE THAT THIS PROGRAM IS OF USE TO YOU, IS THAT YOU SEND ME A SHORT E-MAIL. Yes, I know... This manual has become rather long... I apologise for that, but I think that all things considered, it is best this way. Besides, almost nobody has complained about it so far. :-) I have written this program primarily for my own convenience; the first time I downloaded (a lot of) uuencoded files from the USENET binaries, it took me over four hours to edit everything in such a way that the only uudecoder I had then (a very naive one) could process them. That was a once-but-never- again experience. Starting with version 2.3, UU runs even on 8086 and 8088 processors, so I am once more obeying my "rule" to write programs that are 8086/8088 compatible. (Versions 2.2 and below required at least an 80286.) As for memory requirements: The amount of RAM free for executables should be at least 97k for this program to work correctly: Amongst others, UU uses two 32k buffers to speed up reading and writing, as well as a 14k buffer to store filenames of input files. UU will check if there is enough RAM free, and complain if there is not. (I hear some people asking: "97k?"... Yes, I know we are talking .COM here, but that does NOT mean we are restricted to 64k now, does it?) Starting with version 3.1, UU will be even faster if there is more than the required amount of memory free, since it will use the remaining amount of conventional RAM for additional buffering. I have finally figured out what the minimal DOS version is that this program requires: MS-DOS 2.00. Since I learnt that there still are people using an 8088 based machine, and running MS-DOS 2.10, but I have not heard of any lower versions of MS-DOS still being used, I think that (considering UU's processor, memory, and DOS requirements) I can safely say that UU will run on just about any PC and compatible. UU also runs flawlessly from the DOS box under Windows... Moreover, several people have reported UU running flawlessly from the DOS box under OS/2, and even on DOS emulators on other systems! I suppose I should insert a line here stating that MS-DOS is a registered trademark of Microsoft Corp. As with all the programs I write, a short usage message is included in UU. This message will be displayed by entering either of the following three commands: UU /? UU -? TYPE UU.COM Starting with version 2.0, UU no longer displays a usage message when one merely enters "UU". The reason for this is that I think that one should never get accustomed to invoking a program without parameters or switches just to get help, for there are numerous programs that really do something then. In fact, I have written a program (REMDIR.EXE) that can (depending on whether one really wants it to do what it does then) have disastrous effects then. What I am trying to say is: Never rely on a program to give you help by invoking it without any parameters or switches... Quick instructions ~~~~~~~~~~~~~~~~~~ This chapter contains only the most vital instructions on UU. So if you are in a hurry, and do not have the time to read the entire manual, then read at least THIS chapter. I highly recommend everybody to read the entire manual as soon as they have the time, if only because UU can do a lot more than only what is described in this chapter. Besides, I have put a lot of time in making this manual (and I did not make it for myself...), and reading it in its entirety may keep YOU from asking silly questions, and ME from getting them and having to answer them. :-) If you have one or more files containing uuencoded binaries, then enter the following command from the DOS prompt: UU filename.ext where "filename.ext" is replaced by the actual filename. Wildcards * and ? are allowed, so you will usually not have to use a line like the one above for each separate file. Each of the files you wish to process may contain multiple binaries which may consist of multiple parts, and which will usually also contain non-uuencoded lines. UU does not require you to edit the files first. Just leave everything in -- UU may even perform better that way! If the parts are not in the correct order, then you HAVE TO specify the /S switch. An example: Suppose that you have a directory called C:\DOWNLOAD in which you have put several files containing articles from USENET (note that with UU it is not necessary that all parts of one binary are contained in one and the same file), and that you have a directory called C:\BINARIES in which all uudecoded binaries are to be put. Then, from the C:\BINARIES directory (and assuming that UU is accessible from there), enter the following command: UU/S/D \DOWNLOAD\*.* This will have UU examine all the files in the C:\DOWNLOAD directory, and uudecode everything it can decode from these files. The decoded binaries are put in the current directory (i.e. C:\BINARIES), and all files that have been successfully processed (and ONLY those) are deleted (that is what the /D switch is for). So upon completion, the C:\DOWNLOAD directory will contain only files that do not contain uuencoded parts and perhaps also some files that contain (parts of) uuencoded binaries that could not be successfully decoded. So this way, UU can hugely help you sort out and process the articles. This should get you going if you do not have the time to read the entire manual right now. If you want to know what else UU can do, then simply read the rest of this manual as well. On the uuencoding standard ~~~~~~~~~~~~~~~~~~~~~~~~~~ In my opinion, the uuencoding standard is not very well thought-out. As long as an encoded file consists of only one section (in the early days, splitting an encoded file up into more than one section was most probably not allowed), there is not much wrong with the standard, but as soon as the necessity rose for files to be split up, the standard should have been changed as well. To start with, there is no standard way of designating non-section parts, so the standard provides us with no means whatsoever to distinguish between encoded sections and mere comments. Also, the standard does not describe a way of deciding which sections belong together, nor in which order. Most uuencoders put such additional information in the files, but with the lack of a standard, almost every single one of them has its own way of doing this. A number of encoders will also put one or more checksums in the file, but again, this has not been standardised. It would have been very easy to devise a standard for adding such additional information, but it has not been done, and it may be far too late now... Command line parameters, switches, and environment ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Although the usage message says UU [drive:][path]filename[.ext] [/1] [/A] [/D] [/I] [/K] [/O] [/S] , UU allows all kinds of variations on this: Instead of a slash ("/"), a dash ("-") is accepted as well. UU of course accepts both uppercase and lowercase, and ignores irrelevant blanks (spaces). Also, using a switch twice or more has the same effect as using it only once. Moreover, switches (currently, the switches are /1, /A, /D, /I, /K, /O, and /S) may be combined, and the order in which the filename and the switches (if any) appear on the command line is irrelevant. This means that, for instance, all of the following commands are treated identically: UU example.uue /I /S UU example.uue -I -S Uu exAmplE.Uue/s -I uu/s example.uue/i uu example.uue -is uu /is example.uue uu example.uue /s/i uu/i -sisssis example.uue Please note that if the dash ("-") is used to identify a switch, it must be preceded by at least one blank, since DOS allows dashes also to be part of a filename. Although DOS also allows a dash as the first character of a filename (yes!), UU will not accept an input file with such a name, so if files with such names are to be fed to UU, then they will have to be renamed first. Since dashes are allowed to be anywhere else in the filename, this means that the following two commands are NOT identical: uu temp-i uu temp/i The former command processes a file called "temp-i" using no switches, while the latter will use the switch "i" on a file called "temp". So if the latter interpretation is meant, and one wants to use the dash, then make sure that at least one blank precedes it, as in: uu temp -i There is one exception to the rule that dashes must be preceded by at least one blank when used to identify a switch: If it is preceded by another switch or combination of switches, then the blank is not necessary. So the following command is treated identically to the ones listed at the start of this chapter: uu/i-s example.uue Starting with version 3.2, UU checks for the presence of an environment variable called UU. In this variable, one can specify the default parameter and/or switches. Although one could define this variable directly from the DOS prompt, one would usually put such a definition in the AUTOEXEC.BAT file. Suppose, for example, that one uses UU almost exclusively in combination with the /D, /I, and /S switches, then one could define the environment variable UU as follows: set uu=/dis If one now enters the following command: uu example.uue then this will be interpreted as if there were no environment variable UU, and one had entered the following command instead: uu example.uue /dis The contents of the environment variable UU are ADDED to the command line, so with the same settings for UU as above, the command uu example.uue /k would be interpreted as: uu example.uue /k /dis The environment variable can be overridden by specifying an empty switch from the command line. Empty switches can be specified by entering a slash or dash followed by either nothing or at least one space. The following commands are all interpreted identically, and illustrate several ways of how to specify an empty switch: uu / example.uue /o uu/o example.uue/ uu //o example.uue uu /-o example.uue uu --o example.uue uu -/o example.uue uu - example.uue -o uu example.uue /o- uu example.uue -o - So when an empty switch is specified, the environment variable UU (if present) will be ignored. Finally, please note that the environment variable may also contain a filename specification. For example: set uu=c:\download\*.*/dks set uu=/isd *.uue What UU does, and does not do ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UU is extremely fast, and is even faster when disk caches or RAM disks are used. To illustrate this, I have taken a large uuencoded file (5,915,740 bytes) containing only one part of 93,906 encoded lines, and I have ran UU on it in its fastest mode (i.e. without using any switches) while using different settings. Here is what I came up with on my system (i486DX2-66, VLB, 20 megs RAM, 256k cache): Free memory (kb) 19801 15673 9520 10004 788 SMARTDRV (kb) 0 4096 10240 0 0 RAMDISK (kb) 0 0 0 10240 19456 ----------------------------------------------------- time required (s) 17.5 16.3 8.4 4.8 4.8 This also illustrates that UU spends most of its time reading from and writing to disk (at least on my system), so using faster disk drives (network drives, for instance) can make UU faster yet. UU is extremely robust: Since there is not a well-defined standard on the format of uuencoded files, or on how these should be split up, there are numerous small variations commonly used. The fact that uuencoding is used on most platforms makes things even more complex. (A more detailed description of the kinds of variations that one frequently sees in encoded files may be found in the remainder of this chapter.) I have done my best to make sure the user does not have to worry about all this. Usually, the user only becomes aware of this if he tries other uudecoders, or if (god forbid) UU fails to uudecode a file correctly. I think I can safely say that there is no other decoder that can deal with so many variations in uuencoded files. I just wanted to have one single program that can deal with all common (and even uncommon) "types" of uuencoded files, and not need to choose between a lot of uudecoders every time there is a slight variation in the encoded files. If you do not believe me, just download a lot of uuencoded binaries from USENET, test all your uudecoders on the lot, and judge for yourself which decoder successfully decodes the most files... Of course UU processes both UNIX style ASCII files and MS-DOS style ASCII files. In addition to this, UU also accepts Mac style ASCII files, as well as any mixture of all of these styles. Frequently, files are encountered that have a blank line every other line. This is probably due to the fact that these have been posted from one platform to another without making the necessary adjustments. UU will process such files WITHOUT the need for the user to edit out all these blank lines. Another mess-up that one sees every now and then, is that (probably because the poster had forgotten to turn off word wrapping) the "begin" line is split up into two lines. Starting with version 3.2, UU recognises this. Unlike what I have seen in some other uudecoders, UU does NOT assume an extension of .UUE if no extension is given. This is for my own convenience, since most of the files I get to process have no extension. Although UU was primarily designed to process many multi part uuencoded files all contained in *one* huge file, it can also deal with multiple input files through the use of wildcards. For more information on how UU deals with these, please refer to the chapter on wildcards. Since there is no real difference between UU's handling of single input files and multiple input files, in most of this manual I shall only talk about single input files. The sections in the input file(s) need not be in the correct order at all if UU is used in its "unsorted sections" mode. For more information on unsorted sections, see the appropriate chapter in this manual. If neither of the switches /I and /S are used (and ONLY then), UU does not allow sections to be in any other than increasing order in the file. (Again, please refer to the chapter on unsorted sections for information on how to handle these.) UU always allows the source file to contain more than one uuencoded file, and each of these files may consist of any number of sections. If no switches are used, then these sections MUST be in the correct order. So in this case, a file containing the following sections: <file 1 part 1> <file 1 part 2 (last part)> <file 2 part 1> <file 2 part 2> <file 2 part 3 (last part)> will be handled correctly by UU (and result in two files), whereas <file 1 part 1> <file 2 part 1> <file 1 part 2> <file 2 part 2> <file 2 part 3> and <file 1 part 2> <file 1 part 1> <file 2 part 1> <file 2 part 3> <file 2 part 2> will not. Again, this restriction does NOT apply when UU is told that the file may contain unsorted sections. When used in the "sorted order" mode of operation, UU can handle any number of sections contained in one input file; there is no limit. The only thing that may happen (apart from your hard disk getting full), is that some of the numbers that UU displays will not be correct, but this only happens if the number of sections in one file exceeds 9999. (Yes, I know I used the number 65535 in a previous manual, but that was a mistake. That is what happens when you socialise with computers too much.) If the program terminates or aborts after having detected some error, an ERRORLEVEL of 1 is returned; a successful termination results in ERRORLEVEL 0. Some platforms do not have the restriction of filenames being only at most 8+3 characters long, so the filename in the header of the first section of an encoded file may not be DOS-compliant. UU recognises this, and prompts the user for a new filename. Some platforms allow spaces in filenames. Although it is possible to create filenames containing spaces in DOS (earlier versions of UU would do just that, but only if DOS 5.00 or below was used), starting with version 3.0, UU will replace such spaces by underscores, as filenames containing spaces are just a pain to deal with for most people and programs -- try renaming such files, for instance... Yes, I know it is possible through the use of disk editors or wildcards, but it is more cumbersome than renaming files with "normal" names. Some programs and/or systems chop off all trailing spaces from text lines in a misplaced attempt to save storage space (which is why most uuencoders nowadays use backquotes (`) instead of spaces). Starting with version 3.1, UU correctly decodes these stripped lines. Please note that this makes it possible that UU now decodes files that were considered corrupt before, and that sometimes, these files REALLY were corrupt, so the decoded file will be corrupt too. So realise that if a decoded file is corrupt, that the encoded file usually was corrupt to begin with. There is one exception, however: Suppose that an encoded file contains a line consisting only of an "M", and suppose that this line is NOT an encoded line, but some strange comment line. In this case, UU will think that the line is a chopped encoded line. In UU's "sorted order" mode of operation, this line will then wrongly be decoded, causing the decoded file to be corrupt. Fortunately, this will almost never happen; I have ran UU on many dozens of megabytes of encoded files, and the situation described here did not even occur once! And even if the situation does occur, then please realise that in its "unsorted sections" mode of operation (so when using the switches /I and/or /S), this "section" will usually be skipped because it cannot be identified, so everything will still be alright then. For more information, please refer to the chapter on unsorted sections. If the filename for an encoded file already exists, the user is informed of this, and may then choose to overwrite the old file (by pressing Y), rename the new one (by pressing N), or skip this file and proceed with the next file (if any) (by pressing S). At this point, CTRL-Break (and also CTRL-C) may be used to abort the process. Specify the /K switch if UU is to skip existing files without prompting. Specify the /O switch if UU is to overwrite existing files without prompting for confirmation. Note that the combination of these two switches is meaningless, so UU will issue an error message in this case. If the /D switch is specified, UU will delete all input files that have been successfully processed. This also means that if the sections of some file that cannot be successfully processed are divided over multiple input files, then none of these input files will be deleted. Just like UU processes hidden and read-only files, the /D switch will also delete such files. Files that were skipped (either from specifying the /K switch, or from pressing S when UU asks to overwrite an existing file) also count as being successfully processed. Please note that there is a small difference between UU's handling of the /D switch in its "unsorted sections" mode and in its "sorted order" mode. To wit: In its "unsorted sections" mode (i.e. when using the /S switch), UU will delete only those input files of which ALL sections have been processed, and will NOT delete files that do not contain any sections. In its "sorted order" mode, UU will simply delete all files that have been successfully processed, so EVEN input files that do not contain any sections. As opposed to some other uudecoders, UU does not choke on CTRL-Z characters. UU ignores lines that are not uuencoded, typically before and after sections. I saw somewhere that a uudecoder written by someone else could be notified that (for example) "---" is not a decodable line, as it seems that this line is used as a cut line on several BBS systems. With UU, it is not possible to designate such a non-decodable line... merely because UU does not need that information to determine that a given line is not to be treated as a uuencoded line. UU uses four ways to determine whether a line is a mere comment or not, and treats the line as an encoded line only if all four ways show it is not a comment. These tests are partly performed simultaneously, and always in such a way as to require hardly any additional time (e.g. when the data required for a test is available due to some other action currently being performed). Some uuencoders have the nasty habit of putting one lowercase alphabetic character at the end of every uuencoded line. (These characters are NOT part of the set of characters allowed in uuencoded lines.) UU recognises this without losing any of its intelligence (as meant in the previous paragraph). Although the "standard" requires the "end" line of a uuencoded file to be preceded by a line containing only either one space or one backquote (`), some programs and/or systems replace a one-space-line by an empty line. UU will also process such "illegal" files correctly. Although UU is quite intelligent, it is possible to fool it, but I think that this is purely academic, for the chances of it being fooled are astronomically small (unless someone intentionally fooled UU). Even if one decoded hundreds of thousands of uuencoded files, it would most probably occur not even once that UU was fooled. And if it should ever occur that UU is fooled, then, please, do not blame UU or me, but blame the one who invented the uuencoding standard for not making it more strict. Or, put in another way: All uudecoders can be fooled, but mine must be one of the most reliable ones as I can easily show by a simple computation of probabilities. Of course, UU cannot perform miracles, so if the uuencoded file is corrupt to begin with, UU will be helpless too. But... UU should NEVER actually crash on corrupt files. UUTool-encoded files ~~~~~~~~~~~~~~~~~~~~ Starting with version 3.2, UU also accepts files created by a program called UUTool (which is used on the Apple Macintosh). This is all you need to know about it, since UU does not act any differently towards you if it encounters such files. So the remainder of this chapter is meant only for those who nevertheless want to know a bit more about these files: As opposed to "standard" uuencoded files, UUTool-encoded files also contain lowercase characters. The following is a typical UUTool-encoded line: Mj\LIXg\oOpn^HYFnecgo^TnUjvatY^=<\xJoazRnfoiaHne;frmOfnQIvcFy Another, perhaps easier way to spot such files, is to look at the header of the first section of the encoded file. As far as I know, UUTool is the only encoder that uses "0700" for the UNIX file access code. As in: begin 0700 This is a valid filename on the Mac To accomodate Mac users, UUTool-encoded files often also contain a small file called .rsrc, and sometimes also another file called .finfo -- these files will be of no value in a DOS environment, so UU will automatically skip these if it encounters them. Handling unsorted sections ~~~~~~~~~~~~~~~~~~~~~~~~~~ UU can also handle files containing randomly ordered sections. For this mode of operation, two switches are available: /I and /S. When invoked with /I only, UU will scan the source file, and it will subsequently report what it has found there, but it will not actually decode anything. When invoked with both /I and /S (or any equivalent notation -- see the chapter on command line parameters and switches), it WILL start decoding after having reported the information. A less verbose, but equally efficient result is obtained by specifying only the /S switch. If the /I switch is specified, but not the /S switch, then specifying one or more of the switches /D, /K, and /O does not make much sense. In these cases, UU will act as if only the /I switch had been specified. In particular this means, that in these cases UU will not write or delete anything. There is a maximum to the number of sections that UU can handle using this "unsorted sections"; more details may be found later in this chapter. This mode of operation, however still very fast, is slower than the "sorted order" mode. Starting with version 3.1, the order in which the sections appear does not matter as far as speed is concerned; the "unsorted sections" mode takes approximately twice as long as the "sorted order" mode (versions before 3.1 would take AT LEAST twice as long, but often longer), but the difference may be less on systems using disk caches. Since the "sorted order" mode uses one very powerful assumption (viz. the sections being in sorted order), whereas the "unsorted sections" mode can (at best) only rely on whatever information it filters out of the source file, it is possible for UU to obtain better results in the former mode. So I recommend using the "sorted order" mode whenever one is sure that every section appears in the correct order (which, as noted earlier, also is faster). However, one should realise that in very rare cases, UU may "think" that a line is encoded when in fact it is not. This will typically happen with a text line that starts with an "M", has a length of at most 61 characters, and contains no lowercase characters (all these conditions should be satisfied). The "sorted order" mode will then decode this line, so the decoded file will be corrupt. The "unsorted sections" mode would just skip this "section" because there is not sufficient information available on it. Note that the line does not have to have a length of 61 for this to happen, since it will be considered as a line from which trailing spaces have been stripped if the length is less than 61. So how does UU obtain its information? The current version of UU recognises some 35 different uuencoders and posting programs. (For the ease of discussion, I shall use the term "uuencoders" whenever I mean "uuencoders and/or posting programs" in the remainder of this manual.) These include uuencoders used on PCs, UNIX systems, Macintoshes and Amigas. Below follows a list of (some of) the uuencoders supported by UU: - EnUU, versions 1.3, 1.4, 1.5, 1.6, and 2.02 by Marko Pinteric - Hermes FILESERV by Martin P. Ibert - POST, versions 1.1.0 through 2.0.0 by John W.M. Stevens - post-bin, revision 2.2.2 by Terry W. Thero (REV 2.2 by Rich Thomson) - QUUNCD Ver. 1.4 by Theodore A. Kaldis - SplUU V01.16 beta by Psilocybe Systems Inc. - spluum v1.2 by Benjamin J. Walbeehm - UU-ENCODE, versions 4.02 through 5.27 by Richard E. Marks - UUCODE, versions 2.0 through 3.0 by Sabasoft, Inc. - UULite version 1.6 by Jeff Strobel - UUMaster V4.01 by Philippe Gresse - UUQ version 0.6 by Benjamin J. Walbeehm - UUSPLIT version 1 by David Uy - UUTool version 2.32 by Bernie Wieser - UUXFER ver 2.0 by David M. Read - Wincode, versions 1.2, 1.4, 1.5, 2.2, and 2.3 by George H. Silva - WinVN, versions 0.90.4 through 0.91.3 by Mark Riordan, Sam Rushing, and many others - xmitBin, versions 1.8 and 1.9 by D. Jim Howard Please note that there are many more uuencoders and version numbers of these that are recognised as well by UU, so this list is far from complete. I have listed only the ones that I know by name, and only the version numbers of which I am sure that UU supports them. I just do not have all versions of all these programs, nor uuencoded files produced by all these. Two final notes on the above list: - UUQ has not been released yet! - UUXFER does not always indicate the correct total number of sections, but UU will nevertheless process files encoded by UUXFER correctly! If it cannot recognise the uuencoders that were used, or if these have not included all of the necessary information in the file, UU tries to use the "Subject:" lines (if it finds any) that may be included if the file contains postings from USENET. Instead of "Subject:" lines, some newsreaders produce "Description:" lines; these are also supported by UU. In the remainder of this manual, I shall no longer refer to "Description:" lines, but whatever holds for "Subject:" lines, also applies to "Description:" lines. If postings from USENET are used, I recommend NOT chopping off the headers (and thus the "Subject:" lines) for a higher chance of success. "Subject:" lines are used only if all else fails, because of the higher chance of these containing errors. For instance, someone may have erroneously given a five part file a subject line of "EXAMPLE.ZIP (4/6)" indicating that there are six parts. But even when things like this happen, there is a good chance that UU will successfully decode these files all the same. In particular, this means that UU will usually successfully decode a file containing a series of postings with "Subject:" lines such as the following: Subject: niceprog.exe (2/3) Subject: niceprog.exe (1/3) Subject: niceprog.exe (3/4). Sorry, there are four parts! Subject: niceprog.exe (4/4) Note that this is only an example; all kinds of variations (and also when there actually are LESS parts than the poster originally indicated) of this will usually be processed correctly by UU as well. To end this subject (no pun intended), some examples of "Subject:" lines, and how they will be processed by UU: - Subject: EXAMPLE.ZIP (4/6) UU sees this as part four of a six part file called EXAMPLE.ZIP. - Subject: Re: PICTURE.GIF {Just another picture} [01/10] As expected, UU will see this as part one of a ten part file called PICTURE.GIF. - Subject: Repost:AGAIN.EXE(Part3of20).Reposted on popular demand. Yes, UU will assume it is dealing with part three of a twenty part file called AGAIN.EXE. - Subject: >FOOBAR.JPG (b/w) {Another picture} (part 3/5. UU is not fooled by "(b/w)", nor by the ">"; it will correctly assume this is part three of a five part file called FOOBAR.JPG. - Subject: - FooBar.Jpg {Another picture /0 } part04 of5} (6 /w ). Even this does not fool UU; it assumes to be dealing with part four of a five part file called FooBar.Jpg. Moreover, UU will see this as a further part of the same file as in the previous example. Although these examples show that UU is quite "intelligent" while dealing with these lines, I realise that my "Subject:" line parser still leaves room for improvement. Either way, the name it finds in the "Subject:" line is not all that important since the name of the file also appears in the header of the first section of a uuencoded file. And most of the time (so even when it comes up with false information from the "Subject:" line), it will yield a correct result anyway. And while on the subject of filenames: Most of the uuencoders also include some form of file identification at the start of each (so not only the first) section, one way or another. For at least some of them, it may be the case that this "name" differs from the one that is in the header of the first section. And of course, this is also possible for the name UU filters out of the "Subject:" line. That is why, when using the /I switch, UU will give two names for each section it finds. The real name (i.e. the one from the "begin" line of the first section) is the one that is NOT parenthesised. And although UU will display the names exactly as they appear in the file, it will perform a case-insensitive comparison between these names, thus making up for capitalisation inconsistencies by the person who posted the file. As mentioned earlier, there is a limit to the number of sections that UU can handle when dealing with unsorted sections. Starting with version 2.6, this number depends on the lengths of the filenames it finds in the input file. This is because of the fact that starting with version 2.6, UU stores those filenames in memory dynamically, which means that instead of using a fixed amount of bytes for each filename, it now uses only the amount of bytes it actually needs for each filename. If, for instance, the average length of the filenames (including the ".") is 12, then the maximum number of sections UU will allow is 862. But also note that no matter how short the filenames are, UU will never allow more than 999 unsorted sections. Because of the fact that UU may filter the wrong name out of the "Subject:" line, it is possible that it comes up with the same name for two or more files in case there are several files contained in the input file. If UU cannot find sufficient information from the uuencoder that was used, this may then lead to less successful results than would result if each file were contained in an input file of its own. Stated differently: It is possible that two files that would each be processed correctly by UU, will no longer yield a successful result after they have been concatenated. In particular, this means that when the same file occurs twice in the input file, it will be processed only once. Also when using the /I switch, UU will give the section number and the total number of sections (as far as this could be determined of course) for each section it finds. This is displayed as in "(003/010)", which would mean that this section is part three of a ten part file. Whenever a number could not be determined, "000" is printed instead. Finally (still when using the /I switch only), UU displays some information on any section it will not be able to process, as well as the reason for this. The remainder of this chapter holds for both the /I and /S switches: Whenever a filename that was encountered is longer than twelve characters, it will be displayed to the first eleven characters only, with an asterisk (*) appended to it. Of course, the full name will be displayed when prompting the user for a new filename, and UU will also use the full name in all internal operations. When UU has scanned the input file, it will list the names, and numbers of sections of each COMPLETE file it has found. It also gives the total number of sections it has found, the number of sections it could not identify, and the number of sections that may be processed. Note that the latter number is not necessarily the difference of the former two, because there are various reasons that a section that WAS identified cannot be processed after all (for example when there are other sections of the same file missing). The actual reason will usually be given while using the /I switch. If UU does not give a reason, this usually means that one or more sections appear twice or more. I have done my very best to make UU as smart as possible, but as noted earlier, due to the fact that the uuencoding standard is not strict enough, even the most intelligent uudecoder may not be able to correctly figure everything out. Let me end this chapter by quoting Nick Viner: "Of course some files which have been split by hand and not labelled adequately will always defeat it!" Handling wildcards ~~~~~~~~~~~~~~~~~~ UU accepts wildcards * and ?, and has two switches (/1 and /A) specifically related to this. Basically, if a file specification containing wildcards is used, then UU will act as if the files matching this specification were all contained in one large file. As with single files, each of these matching files may contain multiple multi part files. If the matching files are to be processed fully independently of one another, then use the /1 switch. There is one exception however to the assumption of seeing all these files as if they were contained in one large file: In case UU is used in its "unsorted sections" mode (by using the /I and/or /S switches), then each section should be identifiable. Suppose, for example, that some file has been uuencoded into one single section. If one were to manually split this section into two parts, and save each of these to a different file (say PART1.UUE and PART2.UUE), then UU will not be able to identify PART2.UUE, so invoking UU with UU/IS PART?.UUE will not make UU decode anything. So don't split up sections... Please note that if somebody has split up a large uuencoded file by hand, and has posted each of these parts to USENET, then there is a good chance that each of these parts *will* be identifiable, because the posted parts will have several useful headers (such as "Subject:" lines). The requirement that all parts have to be identifiable of course only applies to UU's "unsorted sections" mode of operation. Usually, the matching files are processed in the order in which they appear in the directory, but UU can be forced to handle these files in alphabetical order by specifying the /A switch. Please note that it does not make much difference whether or not this switch is used when either or both of the switches /I and /S are used as well. To wit, the switches /I and /S force UU to examine all matching files first, and then determine the order in which all sections of all matching files are to be handled, so the order in which these matching files are examined is irrelevant. So the /A switch is only really useful when neither of the switches /I and /S are used. Let us assume that your directory contains the following files (in the listed order): FILE2.UUE FILE3.UUE FILE1.UUE Then, UU FILE?.UUE will process these files in that order, whereas UU FILE?.UUE /A will start with FILE1.UUE, then proceed with FILE2.UUE, and finally process FILE3.UUE. Note that in UU's "sorted order" mode of operation (where files are *not* examined first), sections need not be identifiable, so if one were to uuencode a file into one section, and then manually split up this encoded file into files containing only one line each (let us assume there are 999 lines, and line 1 is written to a file called LINE.001, line 2 to LINE.002, etc.), then UU LINE.* /A will correctly decode it (as will UU LINE.* if the files appear in the correct order in the directory). Note that combining the /1 and /A switches in both UU's "sorted order" and its "unsorted sections" modes of operation does not make much sense, since UU will only terminate successfully if each of the input files is decodable by itself. Or stated differently (using the above example with the files FILE2.UUE, FILE3.UUE, and FILE1.UUE): No matter which additional switches (if any) you use, the command UU FILE?.UUE /X /1 is just an abbreviation for UU FILE2.UUE /X UU FILE3.UUE /X UU FILE1.UUE /X (where /X represents all additional switches). And clearly, there is no difference as to the order in which these commands are given... Well, that is not entirely true as there IS a difference in case the /O switch is used as well, and -- at the same time -- there is some file that appears two times. Suppose, for example, that both FILE1.UUE and FILE2.UUE contain a file called EXAMPLE.ZIP. Then after having used the switch combination /1AO, EXAMPLE.ZIP will be the one that was contained in FILE2.UUE, whereas the combination /1O yields the EXAMPLE.ZIP from FILE1.UUE. The way I see it is that UU simply offers a number of switches, and that it is up to the user to decide whether or not certain combinations are useful. And of course, nobody is forced to actually use all the options UU offers. Finally, a word of advice on using wildcards: If you do not want to spend too much time on USENET, then I suggest you collect all the binaries you want in a few files, don't bother about it if the sections are not all contained in one and the same file, and then run UU on these files using wildcards and the /I and /S switches (e.g. "UU/IS P*"), but please remember that in this mode, there still is the varying limit (as explained earlier) on the number of sections: In case the /1 switch is used, each of the input files may not contain more sections than this limit, and in case the /1 switch is not used, then the sum of the numbers of sections of all input files may not exceed this limit. Plans for the next version (3.3) of UU ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I plan to add a switch that will make UU convert "illegal" filenames to DOS-compliant ones. In combination with the /D, /K, and /O switches, this would enable the user to let UU do its job without ever being asked by UU to answer some questions before it can continue. I think I am going to work on my uuENcoder first though. The current prototype (UUQ version 0.6) is faster than any of the uuencoders I know, and I expect the first public version (1.0) to be faster yet. People who are subscribed to the UU mailing list will receive a copy of UUQ as soon as it is released. Plans for the more distant future ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I can think of several ways of making UU even smarter. For instance, by adding support for even more uuencoders (if I find any). Another option is to have UU use the information it gathers but does not use so far, so as to have it make its own assumptions about sections that could only be partially identified. The latter case would then be as if UU said "These sections probably belong together... well, let's assume they do, and process them.". Finally, the routine that deals with USENET's "Subject:" lines could be made yet a little smarter. I think it would be nice if the user could choose to manually change the "Subject:" lines, thus being able to correct for parts that have not been labelled adequately. Another option I plan to add, is to have UU be able to write every section that has not been processed to a separate file. Related to this would be an option to have UU output all non-encoded data. By using code that runs only on an 80386 or higher, I could make UU yet a bit faster; I may release such a version one day. Or better yet: I could have UU auto-detect the processor, and include processor specific code for the most time critical routines. By using XMS (or EMS) memory for additional buffering, I could make UU yet a bit faster. Some uuencoders put checksums in the files. I may have a future version of UU be able to check these. I may also add support for xxencoded files to UU. Acknowledgements ~~~~~~~~~~~~~~~~ I should like to thank the following persons: - Terry O'Brien for sending me detailed information on the file mode code in the header of uuencoded files, and on uuencoding in general. - Martin Jones for telling me about a bug :-( in version 1.1 (and 1.0). - Brian Norris for telling me about a bug :-( in version 1.3 (and earlier versions). - Douglas Swiggum for all the trouble taken in sending me "strange" uuencoded files, and detailed descriptions of what happened. You have saved me a lot of time in finding two bugs :-( in version 2.0! - Anders Jarnberg for describing exactly what happened while using versions 2.0 and 2.1 under OS/2. - Mike Laskey for telling me about the problems under OS/2, and for testing some preliminary versions of UU 2.2 under OS/2. - Roger Champagne for making me reconsider the way version 2.5 (and earlier versions) handled blank lines. - Robert Bleidt for sending me a file that made me realise that some files that were considered corrupt by UU 2.5 and earlier versions (and still are considered corrupt by almost every other uudecoder) are correctly decodable after all. Thanks also for reminding me that filenames containing spaces (although they *can* be created) are not easily dealt with under DOS. - David Bunch for sending me the line that in a modified form is used in the UUW.BAT batch file that was included in the UU 2.6 package. Yes, I know it has been a while since you sent me that line, but I kept forgetting to include it in the package... - Hoa Nguyen for contributing the UUD.BAT batch file that was included in the UU 2.6 package. - Marko Pinteric for making sure that his uuencoder (EnUU) would be supported by UU. - Paul Erickson, John Gotts, and Bryan Woodworth for their help in setting up a mailing list for UU. - Michael Eilers, David Farley, Spencer Hochstetler, Allan Hudgins, Martin Ibert, Eric Johansson, Alex Law, Rufus P., Terry Thero, Anthony Trippe, David Uy, and Rene Walter for helping me find the names of some of the uuencoders UU recognises. Last but not least, I should like to thank all the people who have let me know they appreciate my program, or otherwise (e.g. by telling me about bugs, or suggesting new features) mailed me regarding UU. Release history ~~~~~~~~~~~~~~~ In my convention of version numbers, 0.x versions denote usually unreleased prototype versions. Versions 0.1 through 0.4, and 0.6 were private, unreleased versions, written in a mixture of Pascal and assembly language. Version 0.5 was given to but a few people to see how they liked it. It had resulted from a process of stepwise refinement in which speed, size, feedback, and user-friendliness were tackled. Versions 0.1 through 0.5 were all written on 11-Dec-93. They were EXE files, and the latter had a size of 5872 bytes. UU 0.6 Type: EXE Size: 3424 Date: 14-Dec-93 The last prototype version. Most of it written in assembly. Yet a bit faster than 0.5. UU 1.0 Type: COM Size: 1993 Date: 15-Dec-93 The first publicly released version. But for some tiny details this is the full-assembly version of 0.6. UU 1.1 Type: COM Size: 1965 Date: 18-Dec-93 - Even smarter in distinguishing comment lines from encoded lines (a fourth test has been added). - Sections containing only one non-empty line are now recognised as such. - Detects when the disk is full, upon which it aborts with an appropriate message. - Yet a bit faster than 1.0. UU 1.2 Type: COM Size: 1896 Date: 23-Dec-93 - Now really only accepts "y", "Y", "n", and "N" while asking permission to overwrite an existing file. Also, CTRL-Break (and CTRL-C) can be used at this point to abort the program immediately. UU 1.3 Type: COM Size: 1892 Date: 25-Dec-93 - In earlier versions, lines of more than 255 characters COULD (although it is HIGHLY improbable they actually WOULD) result in decoded files being corrupted; starting with this version, this can no longer happen. - Yet a bit faster than 1.2 (amongst others (but not only!) because the read and write buffers now each are 4k larger). UU 2.0 Type: COM Size: 5866 Date: 09-Jan-94 - Now also allows files containing unsorted sections. - An intelligent command line parser has been added. Because of this, the bug of UU not accepting filenames of length 1 in the command line (in fact, I did not even know about this bug until some time after I had finished the parsing routines) no longer exists. - Aborts with an appropriate message if there is not enough (conventional) RAM free. - Displays an error message when invoked without any parameters or switches. UU 2.1 Type: COM Size: 6257 Date: 17-Jan-94 - I really thought I had solved the problem of lines containing more than 255 characters in version 1.3, but I had not; now, it is REALLY fixed. - Added support for five more uuencoders and posting programs. - In addition to "Subject:" lines, "Description:" lines are now supported as well. - Made the parser for "Subject:" (and "Description:") lines even more intelligent. - Fixed a bug that seemed to matter only when run from the DOS box under Windows. - The maximum number of unsorted sections UU can handle is slightly higher (434 instead of 387). - Some minor changes not worth mentioning. UU 2.2 Type: COM Size: 6453 Date: 29-Jan-94 - Faster than all previous versions, even more so (due to a bit of manual code optimisation I performed) for those lucky few owning a Pentium. - Now recognises corrupt final sections (which could cause UU to crash in earlier versions). - The "Subject:" line parser is yet a bit smarter. - A bit smarter in recognising the uuencoders and posting programs. - Also a bit smarter in making up for errors in the "Subject:" line. - And also a bit smarter in recognising false "begin" lines. - Supports five more uuencoders and posting programs. - Now also runs from the DOS box under OS/2. - Sections containing only an empty line followed by the end marker are now recognised as such. - While working on the previous point, I discovered and fixed a bug: Previous versions did not handle very short encoded lines correctly; they would cause a file to be one byte too short. UU 2.3 Type: COM Size: 6450 Date: 13-Feb-94 - Still as fast as version 2.2, although UU now also runs on 8086 and 8088 processors. - Now also accepts files created by uuencoders that put one lowercase letter at the end of every uuencoded line -- previous versions of UU would either crash, or come up with a resulting file of 0 bytes in these cases. - Yet another five additional uuencoders and posting programs are supported. - Some internal changes were made to make UU smaller; without these changes, this version would have been over 300 bytes larger. UU 2.4 Type: COM Size: 6470 Date: 03-Mar-94 - Previous versions of UU would sometimes not handle filenames of longer than 28 characters correctly -- this has been fixed now. - Discovered and fixed a bug that by some weird coincidence never seemed to matter. - Some tiny changes not worth mentioning. UU 2.5 Type: COM Size: 6490 Date: 13-Mar-94 - Version 2.4 would sometimes display "strange" filenames (viz. a digit followed by a blank, followed by the real filename). Fixed. - In some other cases, UU would produce a filename of length zero when this should not have been the case -- this has now been fixed. UU 2.6 Type: COM Size: 6695 Date: 07-Apr-94 - In addition to DOS style ASCII files and UNIX style ASCII files, Mac style ASCII files are now accepted as well. - Fixed a tiny bug that on some occasions would display section numbers that did not start at 1 in UU's "sorted order" mode of operation. - Blank lines in encoded sections are now ignored, so UU now correctly decodes postings that have a blank line following every "normal" line. - Some files that were considered corrupt before (and still are considered corrupt by almost every other uudecoder!), will now be decoded correctly. - Filenames are now stored in memory dynamically, thus usually allowing much more unsorted sections (usually well over 800 sections, but at most 999). - One more uuencoder is supported. - Several (other) internal changes were made in preparation for version 3.0. UU 3.0 Type: COM Size: 7614 Date: 26-Apr-94 - Now also accepts wildcards. Related to this, two new switches (/1 and /A) were added. The files UUW.BAT and UUD.BAT that were contained in the package of version 2.6 have thereby become superfluous. - Added a new switch /O for overwriting existing files without confirmation. - Although the standard requires the "end" line to be preceded by a line containing only a space or a backquote (`), UU does no longer require it, since there are programs/systems that replace this line by an empty one. This change was also made in preparation for version 3.1. - Some systems allow spaces in filenames. Although it is possible to create filenames containing spaces in DOS (earlier versions of UU would do just that, but only if DOS 5.00 or below was used), UU will now replace such spaces by underscores. - A small program (FROMMAC.EXE) is included in the package to deal with files produced by a Mac program called UUTool. - One more uuencoder is supported. UU 3.1 Type: COM Size: 8318 Date: 24-May-94 - Faster than all previous versions, and even more so if it can use one or more extra buffers: UU still requires very little memory to run, but it will put all additionally free conventional RAM (if any) to good use now. - Usually much faster in its "unsorted sections" mode, because the order in which the sections appear now is irrelevant as far as speed is concerned. Even when the sections appear in reversed order (which was the worst case for previous versions), UU is still as fast as in the best case now. - Some programs and/or systems chop off all trailing spaces from text lines in a misplaced attempt to save storage space (which is why most uuencoders nowadays use backquotes (`) instead of spaces). UU now correctly decodes these stripped lines. - Added a new switch /D for having input files that have been SUCCESSFULLY processed deleted. - Added a new switch /K for skipping existing files without prompting. - Files that already exist may now be skipped by pressing "S" when UU prompts for it. UU 3.2 Type: COM Size: 8624 Date: 19-Jun-94 - Defaults can now be specified in an environment variable ("UU"). - Now correctly decodes files of which the "begin" line is split up into two lines. - Now also decodes files encoded by a Mac program called UUTool. The FROMMAC program that was contained in the UU30 and UU31 packages, has thereby become superfluous. - Four more uuencoders (one of which is UUTool) are supported. - Several small cosmetic changes were made. How to get on the UU mailing list ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ If you want to receive a (ZIPped and uuencoded) copy of UU by e-mail every time a new version is released, here is what you should do: Send an e-mail with the subject line "Subscribe UU mailing list" to Walbeehm@fsw.ruu.nl, and make it have the following contents (I am using myself as an example here): Name: Ben Jos Walbeehm Address: Walbeehm@fsw.ruu.nl Country: The Netherlands The reason I want to know which country you live in (no, it can not always be determined from the e-mail address), is merely because I am interested in the usage statistics of my program. Note that you have to explicitly specify the e-mail address you want copies of my uudecoder to be sent to. And since I am having some small program I wrote take care of dealing with the subscriptions (to save myself time), mails that do not have at least all four "ingredients" (i.e. subject line, name, address, and country) will be ignored. Once you have been put on the mailing list, an acknowledgement will be sent to the address you specified at "Address:". It will contain some more details as well. This acknowledgement should take at most a few days; if you have not received it a week after you have sent your mail, please try again. Oh yes (this is VERY IMPORTANT), as you probably know, all I ask in return for my program is a short e-mail telling me you are using it. Your subscription to the mailing list does NOT count as such... Finally: I am providing this service for free, but since I have to pay for the account I run the mailing list from, I actually lose money on it. I absolutely *HATE* to charge any money for UU, so I am going to look how everything runs first without asking any money for it. I actually have to pay for connect time, but I have no idea how long it takes to process the mailing list, so I may feel forced to ask a very small contribution (at most two or three dollars for as long as the mailing list will be in existence) in the future, but I shall try not to. If ever I do, you will all get the chance to unsubscribe from the list first. :-) Contacting the author <-- Hey, that's me! :-) ~~~~~~~~~~~~~~~~~~~~~ Contact me (preferably using e-mail) if you have any questions, suggestions, remarks, etc., on this document, on UU, or on any other of my programs. Also, if you find a valid uuencoded file that UU does not process correctly, please let me know. And if at all possible, pray send that file along to me (or otherwise a detailed description of its contents). If you do send me a file, please send it to my second account (Walbeehm@kali.cc.ruu.nl), because the first one will most probably screw the file up before it actually gets to me. Thank you very much! I check the alt.binaries.pictures.misc and alt.binaries.pictures.utilities newsgroups on USENET regularly, so you could also try placing messages for me there. Finally, please send me an e-mail if you think my program is of use to you (or flame me if you think it is useless). If I do not get enough feedback, I take it that people are not interested, and I shall... continue writing programs for myself, but DIScontinue spreading them on anything but a very small scale. Ben Jos Walbeehm (Please get my first name right, it is "Ben Jos".) Lijsterbeslaan 20 5248 BB Rosmalen The Netherlands Phone : +31 4192 14345 (The best time (GMT) to get hold of me is at night!) E-mail: Walbeehm@fsw.ruu.nl (Monday through Friday) E-mail: Walbeehm@kali.cc.ruu.nl (7 days a week, but I have to pay for it)