The First Hungarian Family/The_First_Hungarian_Family_CD-ROM.bin/internet/coddecod/uu40s/uu.doc

Text File | 1995-04-10 | 82KB | 1,407 lines

      UU version 4.0  --  A small, fast, and smart uudecoder for DOS
        Copyright (C) April 1995  --  ir.drs. Benjamin J. Walbeehm

                              April 10, 1995


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
           -  Creating DOS-compliant filenames
           -  Plans for future versions of UU
           -  Acknowledgements
           -  Release history
           -  How to get the registered version of UU
           -  Contacting the author

If you are pressed for time, then I suggest you read "Quick instructions"
now, and the rest later.


Introduction
~~~~~~~~~~~~
UU is a so called uudecoder, which means that it decodes files that have been
encoded using the uuencoding standard. This form of encoding is one of the
standards used for transferring files over computer networks. Originally, it
was devised for transferring files from UNIX to UNIX systems (hence the "uu"
in "uuencoding"), since binary files (programs, graphics files, data files
from all kinds of programs, etc.) could not be sent over the networks in their
original form. Nowadays, the standard is used on lots of other platforms as
well, and it is very popular on USENET (which basically is a collection of
discussion and exchange forums on the Internet).

My uudecoder is specifically designed for MS-DOS systems (either real or
emulated). Since some systems severely limit the size of uuencoded files,
files are often split up into several parts, but since the uuencoding standard
does not describe a standard way of marking the part numbers, or distinguishing
uuencoded lines from plain text lines, retrieving binary files from uuencoded
files can cost a lot of effort. It requires a lot of editing to get a batch of
uuencoded sections in a form that a naive uudecoder can successfully handle.
Hence the need for smart uudecoders. Smart uudecoders take away the need for
the user to first strip out non-uuencoded information from the files and sort
the sections. The smarter the uudecoder, the less trouble the user has to go
through to retrieve the binary files.

I claim my uudecoder, UU, to be the smartest available for DOS, and I have not
seen any uudecoders on other platforms that came close to UU either. This is
confirmed by lots of people who have asked me for versions of UU for other
platforms. As of now, UU has not been ported to other platforms yet. The main
reason for this is that UU has not been written in a higher language such as
C++ or Pascal, but in native 80x86 machine code. I do, however, have plans for
at least Windows and UNIX versions of UU, but I cannot say yet if and when.

Starting with version 4.0, UU is shareware, which means that you can freely
use UU for evaluation purposes, but no longer than 30 days. If you decide that
UU is of use to you, then you have to register. In return, you will receive
the registered version of UU, which is even more powerful. See the chapter
on registering UU for the details. You can freely copy and distribute the
SHAREWARE version of UU, but only under the following conditions:
  -  You are not allowed to charge any money for it, although a small fee (no
     more than 5 US dollars) is allowed for materials and handling.
  -  If the SHAREWARE version is put on a BBS or a similar forum, then it HAS
     to be downloadable free of charge (with the possible exception of usage
     fees that have to be paid anyway for facilities such as those). (THE
     REGISTERED VERSION MAY NOT BE DISTRIBUTED IN ANY SHAPE OR FORM.)
  -  Only distribute the complete, original, unmodified package. It IS allowed
     to encode the COMPLETE package with a uuencoder or any other encoder used
     used to send binary files over networks, but the package and its contents
     still have to be complete, original, and unmodified then.
  -  Including UU on CD-ROM, or in a book is allowed. I would appreciate it
     very much if I were sent a free copy in these cases.

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. :-)

This program started out as something I wrote 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. So I wrote UU, and I uploaded that first
version (1.0) to some USENET newsgroups. The response I got was huge. People
loved my uudecoder (even that very first version), so I decided that I would
make it freeware. About 1 year and 15 versions later, I was forced to leave
the net for a while, and by that time, there were hundreds of people from
over 35 countries all over the world whose favourite uudecoder was... mine.
So when the moment of my return neared, I started upgrading UU again. Due to
my marriage (I had met an American girl over the Internet (yes!) in July 1994,
and from that moment on, we spent at least 6 hours every day talking to each
other over the net (IRC), until we finally met in person on October 10, 1994.
And on January 27, 1995 we married.), and my emigration from the Netherlands
to the United States, I decided to change UU's status from freeware to
shareware. And that's how it happened. :-)

Before you ask me for the source code so you can compile it on other platforms,
let me tell you that UU was entirely written in assembly, so compilers would
not do you any good...

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 99k 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: "99k?"...  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 [drv:][path]filename[.ext] [/1] [/A] [/C]
[/D] [/I] [/K] [/O] [/Q] [/R] [/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, these are /1, /A, /C, /D, /I, /K, /O, /Q, /R,
and /S) may be combined, and the order in which the filename specification 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 either have to be renamed first
or a wildcard will have to be used (e.g. to decode a file called "-EXAMPLE",
one could use a "?" wildcard instead of the "-", as in "UU/S ?EXAMPLE".
Please refer to the chapter on wildcards for more details on their usage).
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.

Please note that the environment variable may also contain a filename
specification. For example:
    set uu=c:\download\*.*/dks
    set uu=/isd *.uue

Finally, a short description of each of the switches. Most of them will be
discussed in more detail later in this manual.

    /1    Makes UU process each of the files that match the given filename
          specification on the command line in isolation. So if a directory
          contains 3 files matching "*.UUE" (say FILE1.UUE, FILE2.UUE, and
          FILE3.UUE), then "uu *.UUE /isd /1" is merely an abbreviation for
          the three commands "uu FILE1.UUE /isd", "uu FILE2.UUE /isd", and
          "uu FILE3.UUE /isd". This switch is useful only if wildcards are
          used.
    /A    Makes UU process each of the files that match the given filename
          specification on the command line in alphabetical order. So the
          filenames of the files matching the specification are sorted first,
          and then processed by UU in this sorted order. This switch is useful
          only if wildcards are used, and usually useLESS if the /I and/or /S
          switches are used.
    /C    Makes UU create DOS-compliant filenames for the files it decodes.
          Often, files have been encoded on platforms that allow much more
          freedom than DOS in creating filenames (for instance, they can be
          much longer than the maximum length (8+3) of DOS filenames). This
          switch will transform non-compliant names into compliant ones that
          resemble the original name. This switch is available only in the
          registered version.
    /D    Deletes all files that have been successfully processed. If, for
          instance, a file contains 10 uuencoded sections, then this file
          will only be deleted if all 10 sections have been successfully
          processed (so if each of the 10 sections has either been written
          to disk or skipped because the file to which it belonged already
          existed).
    /I    Makes UU display additional information on the files it scans. If
          used without the /S switch, then UU will only examine the files and
          report what it has found, without actually decoding anything. If
          used in combination with the /S switch, then UU will proceed with
          decoding what it has found. This switch has no effect whatsoever on
          the way the /S switch would process the files. It can be used either
          to make UU more verbose while processing the files (in combination
          with /S), or to have UU examine files only (without the /S switch)
          to see if they contain anything decodable, upon which the user can
          then decide whether or not to have UU actually decode the files.
    /K    Skips existing files without prompting for confirmation. If UU
          encounters a uuencoded file that upon uudecoding would get the
          same filename as one of the files that already are in the current
          directory, then this encoded file will not be decoded. UU will,
          however, mark this encoded file as being successfully processed,
          so the file in which it is contained will be deleted through the /D
          switch if everything else in it is also marked as being successfully
          processed. In other words: If two or more files would turn out to
          have the same name, then only the first one will "survive".
    /O    Overwrites existing files without prompting for confirmation. If
          UU encounters a uuencoded file that upon uudecoding would get the
          same filename as one of the files that already are in the current
          directory, then UU will automatically uudecode the encoded file,
          replacing the file that was already there. In other words: If two
          or more files would turn out to have the same name, then only the
          last one will "survive".
    /Q    Makes UU quiet. Without this switch, UU will beep on warnings and
          errors, but if /Q is specified, UU will not beep then. UU *may*
          still beep though in this case, but the only possibility of this
          happening is if it finds something wrong in the command line
          before the /Q is encountered. For instance: If the command line
          is "UU /b/q *.*", then as soon as UU sees "/b", it will issue a
          beeping error message (since "/b" is a non-existing switch), so it
          will not process the rest of the command line and hence never see
          the "/q". Note that "UU /q/b *.*" would have resulted in a quiet
          error message.
    /R    Uniquely renames existing files without prompting for confirmation.
          If UU encounters a uuencoded file that upon uudecoding would get the
          same filename as one of the files that already are in the current
          directory, then UU will create a unique name for this encoded file.
          The unique name UU creates will have the same extension (if any) as
          the original name (say ".ext"), and will be the first non-existing
          name in the range "UU-00001.ext" through "UU-99999.ext". This switch
          is available only in the registered version.
    /S    Makes UU attempt to sort the sections it finds. Instead of decoding
          the sections in the order it encounters them, UU will examine each
          of the sections first to determine the order in which to decode
          them. To this end, UU uses all information it can identify outside
          the encoded parts of the uuencoded files. Sections that cannot be
          identified (so if the additional information does not give UU any
          clues as to the section numbers of one or more sections), will not
          be processed. This switch HAS to be used if UU is to successfully
          decode sections that are not in the correct order.


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. The registered version of UU can, if so desired,
fully automatically create DOS-compliant names from non-compliant ones.

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:
  (1)  Overwrite the old file (by pressing Y). If the user tries to have UU
       overwrite a file that is read-only, UU will show a message that the
       filename is invalid, and the user will be prompted to enter a new
       filename. So UU will NOT overwrite read-only files.
  (2)  Not overwrite the old file (by pressing N). The user will be prompted
       to enter a new filename.
  (3)  Have UU create a unique filename for it (by pressing R). This choice
       will only be accepted in the registered version!
  (4)  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.
Overwriting, skipping, and uniquely renaming can also be done automatically
by UU:
  -  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. Again, UU will NOT overwrite read-only files.
  -  Specify the /R switch if UU is to uniquely rename the new files without
     prompting (registered version only!). The unique name UU creates will
     have the same extension (if any) as the original name (say ".ext"), and
     will be the first non-existing name in the range "UU-00001.ext" through
     "UU-99999.ext". For instance, if a file contains 2 uuencoded files, say
     "EXAMPLE.ZIP" and "WHATEVER", and if both of these names already exist,
     then UU will create the files "UU-00001.ZIP" and "UU-00001" instead
     (provided that these do not yet exist of course). If the same file were
     then fed to UU again with the /R switch specified, then this time, the
     files "UU-00002.ZIP" and "UU-00002" would result. I think you get the
     picture. :-)
Note that any combination of these three switches is meaningless, so UU will
issue an error message in these cases.

If UU reports that a filename is invalid while it SEEMS valid, then there most
probably already is a DIRECTORY with that name. Another possibilities is that
the filename is already in use as a VOLUME LABEL. Or else, the user had told
UU to overwrite an existing file (either through answering "Y" when UU asked
if the file was to be overwritten, or through the use of the /O switch) that
turned out to be read-only.

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 /C, /D, /K, /O, and /R 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 in this
"unsorted sections" mode; 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:
 -  DISPLAY 1.87 by Jih-Shin Ho
 -  EnUU, versions 1.3, 1.4, 1.5, 1.6, 2.02, and 2.1 by Marko Pinteric
 -  Hermes FILESERV by Martin P. Ibert
 -  POST, versions 1.1.0 through 2.0.1 by John W.M. Stevens
 -  post-bin, versions 1.3, 2.1, and 2.2 by Rich Thomson, and revision 2.2.2
        by Terry W. Thero
 -  QUUNCD Ver. 1.4 by Theodore A. Kaldis
 -  SplUU V01.16 beta by Psilocybe Systems Inc.
 -  spluum versions 1.2 and 1.3 by Benjamin J. Walbeehm
 -  USplit V1.45 by Steven P. Innell
 -  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.0.3, 1.2, 1.4, 1.5, 2.2, 2.3, and 2.6.1 by
        George H. Silva
 -  WinVN, versions 0.90.4 through 0.91.4 by Mark Riordan, Sam Rushing,
        John Cooper 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 usually 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.

Some more on the wildcards themselves now: First note that only filename and
extension may contain wildcards. If a drive and/or path are specified, then
these may NOT contain wildcards. So "UU C:\DOWNLO*\*.*" is not allowed. UU
will report it has found no filenames matching this specification in this
case. Secondly, UU is more intelligent in handling wildcards then DOS is.
For instance, DOS would ignore the "r" in "*r*.*" -- UU will not!  UU will
consider all files that have an "r" ANYWHERE in their PROPER filenames. By
"proper filename" I mean the filename without the extension (if any). This
distinction makes talking about wildcards in this part of the manual a bit
easier. As usual, "*" means: "Zero or more characters", and "?" means:
"Exactly one character", and of course, matches are case insensitive.
For example, consider a directory consisting of the following files:
    1
    1.PAS
    A
    A.EXE
    E
    EXAMPLE.ZAP
    EXAMPLE1.ZIP
    FILENAME
    WHATEVER

Now some specifications, and their results on this directory:
    *          Matches all files.
    *.*        Matches all files.
    *.         Matches all files without an extension, so: 1, A, E, FILENAME,
               and WHATEVER
    *.?*       Matches all files with an extension (Note that "?*" means:
               "One or more characters"), so: 1.PAS, A.EXE, EXAMPLE.ZAP,
               and EXAMPLE1.ZIP
    ?.*        Matches all files of which the proper filename has exactly one
               character, so: 1, 1.PAS, A, A.EXE, and E
    *a*        Matches all files with an "a" somewhere in the proper filename
               and/or in the extension, so: 1.PAS, A, A.EXE, EXAMPLE.ZAP,
               EXAMPLE1.ZIP, FILENAME, and WHATEVER
    *a*.*      Matches all files with an "a" somewhere in the proper filename,
               so: A, A.EXE, EXAMPLE.ZAP, EXAMPLE1.ZIP, FILENAME, and WHATEVER
    *.*a*      Matches all files with an "a" somewhere in the extension, so:
               1.PAS and EXAMPLE.ZAP
    *e         Matches all files with an "e" as the last character of the
               filename. If there is no extension, then the last character
               of the proper filename is considered, and if there IS an
               extension, then the last character of the extension is
               considered, so: A.EXE, E, and FILENAME
    *e.*       Matches all files with an "e" as the last character of the
               proper filename, so: E, EXAMPLE.ZAP, and FILENAME
    e*         Matches all files with an "e" as the first character of the
               (proper) filename, so: E, EXAMPLE.ZAP, and EXAMPLE1.ZIP
    *e*a*.*    Matches all files that have an "e" somewhere in the proper
               filename, where an "a" follows somewhere behind that "e",
               while having any extension (so also none), so: EXAMPLE.ZAP,
               EXAMPLE1.ZIP, and FILENAME

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.


Creating DOS-compliant filenames
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Filenames often are not DOS-compliant because most other platforms allow much
more freedom for filenames. UU can automatically transform non-DOS-compliant
filenames into compliant ones. This feature is not available in the shareware
version though!

In order to transform a non-compliant filename into a compliant one, UU is
equipped with a dozen or so algorithms to shorten the filename. As soon as UU
is left with a compliant name, it stops shortening the filename. Usually, the
compliant name looks a lot like the original name. For instance, the name
"LittleTooLong.jpeg" would be transformed into "LITLTLNG.JPG". Specify the /C
switch if UU is to make DOS-compliant filenames. Another function UU performs
when this switch is specified, is that it strips drive and path specifications
from the filename. This works on both DOS and UNIX path specifications, so
both "C:\UTIL\UU40R.ZIP" and "/util/uu40r.zip" would result in "UU40R.ZIP".
Sometimes, UU will not be able to create a compliant filename. This usually
happens when the original filename is empty, or consists of an extension only
(as in ".ircrc"). In these cases, UU will create a unique name. Unique names
are explained earlier in this manual.

Before using the /C switch, it is important to realise a few things. Although
the /C switch is meant to have UU do its decoding unattendedly, it is not
always sufficient to NOT have UU prompt the user for some input. To wit,
without the /C switch, UU will interrupt its decoding in any of the following
cases:
  1. The filename UU tries to create already exists.
  2. The filename UU tries to create is invalid because it is empty, only has
     an extension, or consists of illegal characters.
  3. The filename UU tries to create is invalid because the name is already
     used as a DIRECTORY or VOLUME LABEL.
  4. The filename is too long.
  5. UU was told to overwrite an existing file, but this file turned out to be
     read-only.
  6. The disk is full.
  7. A a bad sector was encountered on the disk.

If the /C switch is specified, but none of the switches /K, /O, or /R, then
UU will still interrupt its decoding in cases 1, 3, 6, and 7. In order to
have UU do its decoding "more automatically", the /C switch should be used
in combination with either /K, or /O, or /R. But you have to realise that
the transformation of a name into a DOS-compliant one may result in having
the same name for two files that originally had different names!  That is why
I suggest not to use /C in combination with /K (skip existing files), or /O
(overwrite existing files). If you do use one of these switches, however, then
you should know that cases 3, 6, and 7 apply for /C/K, and cases 3, 5, 6, and
7 for /C/O. I recommend using /C/R, in which case existing files get a unique
name. Moreover, the combination /C/R will also create a unique name in case 3,
thus leaving only cases 6 and 7. So if there are no unmarked bad sectors on
the disk, and there is plenty of disk space, then /C/R will make UU do all the
decoding without ever prompting the user for input. So for example: A batch of
unsorted uuencoded files could then be decoded fully automatically by entering
the command "UU /risc *.uue".


Plans for future versions of UU
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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 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.

I got an e-mail from someone who told me that some program called CROSSPOINT
(XP) does not produce "Subject: " or "Description: " lines, but something
else. Can anybody tell me what it is, or better yet, send me an example of
a uuencoded file obtained through XP?

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.

Log files. Some people "complained" that UU was too fast: The information UU
provides while decoding usually scrolls by very quickly. Having UU write the
relevant output to a log file could solve the problem of not being able to see
what UU has done. And with the introduction of the /C and /R switches, this
feature has become even more desirable.

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.
 -  Wolfgang Schwendt and Jason Zavaglia for drawing my attention to the
    several formats used by some FTPmail-servers.
 -  Michael Eilers, David Farley, Spencer Hochstetler, Allan Hudgins, Martin
    Ibert, Steven Innell, 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,
suggesting new features, or suggestions on improving this manual) mailed me
regarding UU. I have tried to send each and everyone of you an e-mail back,
but for reasons beyond my control, a few times this was not possible...


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.

UU 3.3   Type: COM   Size:  8917   Date: 02-Oct-94
 -  In very, very rare cases, UU would identify a file, but "forget" to
    actually process it. This has been fixed.
 -  Improved recognition of invalid filenames.
 -  Several formats used by FTP mailers are now supported.
 -  Two more uuencoders are supported.

UU 4.0   Type: COM   Size: 10140   Date: 10-Apr-95
 -  Improved handling of stripped encoded lines.
 -  More powerful wildcard handling: Characters following an asterisk (*) are
    relevant now, and several asterisks may be used, thus allowing many more
    types of filenames to be specified through the use of wildcards.
 -  Added a new switch /C for having UU create DOS-compliant filenames.
    (Registered version only!)
 -  Added a new switch /Q for making UU quiet. If this switch is specified,
    then UU will not beep. Otherwise, UU will beep on warnings and errors.
 -  Added a new switch /R for renaming existing files to a unique name without
    prompting. (Registered version only!)
 -  Files that already exist may now be automatically renamed to a unique name
    by pressing "R" when UU prompts for it. (Registered version only!)
 -  One more uuencoder is supported.
 -  Changed UU's "status" from freeware to shareware.
 -  New e-mail address.


How to get the registered version of UU
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Yes, I know how easy it is... You get a shareware version of a product, and
you use it, and use it, and keep using it without ever registering, even
though registering a piece of shareware usually is much, much cheaper than
buying a commercial piece of software, and even though it is a GREAT piece
of shareware. (Why else would you use it so much?)  Yes, it is even cheaper
not to pay, but if shareware authors find out that everybody is using their
programs without ever registering, then they just stop distributing their
programs. And you can't enjoy their quality software releases anymore.

OK, on a lighter note now: As with most shareware products, there are
incentives for registering THIS particular piece of software. The advantages
of becoming a registered user of UU are:
  1. The registered version of UU comes equipped with the very useful and
     very powerful /C and /R switches. Details on these switches may be found
     elsewhere in this manual.
  2. UU 4.0 will be the last version that comes both as a shareware and a
     registered version. I shall not upgrade the shareware version anymore.
     Whenever I have finished an upgraded registered version, I shall upload
     a description of the new features to forums such as USENET, but the old
     shareware 4.0 version will accompany it. Since new uuencoders, posting
     programs, etc. are released daily, and since the old 4.0 will probably
     not support those, this means that the shareware version will become less
     and less useful...
  3. Whenever I have a new version of UU, I shall immediately notify the
     registered users. This saves you the trouble of checking the FTP sites,
     or alt.binaries.pictures.utilities, or whatever to see if there perhaps
     is a new version of UU. You will also be told then exactly what the
     changes are in comparison to the previous version of UU, so that you
     can decide whether or not to get the upgraded version. Even if you
     decide not to upgrade your registered version, then I shall still keep
     your name on my mailing list, so that when the next version appears, you
     will again be notified. And of course, I shall also let you know whenever
     I release other programs. (The old mailing list for UU (when it was still
     freeware) no longer exists.)
  4. My support. I think that in the past (when UU was freeware), I have been
     very helpful to all users. Because I shall not be having as much time as
     I had then to spend on helping people, this means that I shall be more
     helpful to registered users. If you have any problems using UU, tell me.
     If you encounter something you cannot decode, let me know.
  5. Intangible considerations. Hundreds of people have let me know they like
     UU very much. Lots of people have told me they would pay for it if it had
     not been freeware then. Several people have even sent me money although
     it was freeware then. UU saves a lot of people a lot of time. Registering
     UU is your way of showing me your appreciation. It is the right thing to
     do. If a program is worth using, it is worth paying for as long as the
     price isn't outrageous. And registering UU is very inexpensive. And if
     you want to enjoy my releases in the future, then don't give me any
     reasons to stop releasing programs.

Registering UU is very inexpensive: If you have an Internet e-mail address,
it will cost you only US$10. The package containing the latest registered
version will be sent to you by e-mail then in uuencoded form. If you cannot
handle uuencoded mailings, let me know, and I shall send you the self-decoding
version of the package. If there are any other restrictions (such as a maximum
size of attachments of e-mails sent to you), then please let me know.

For people who wish to receive a registered copy of UU on 3.5" floppy, the
registration fee is US$15.

Once you are a registered user, you will always remain a registered user,
unless I find out you did not obey the rules for users of the registered
version. The package you will receive when you register will contain a file
called README.1ST in which these rules are listed. As a registered user,
you can get upgrades by e-mail for 3 US dollars, or by snail-mail (on a 3.5"
floppy) for 8 US dollars.

PLEASE DO NOT SEND ME ANY OTHER CURRENCY THAN UNITED STATES DOLLARS!!!
This means that you should not send me any Dutch guilders either, since I no
longer live in the Netherlands. I am a United States resident now.

Send a letter with your (1) name, (2) address, (3) country, (4) e-mail address
(not necessary if you want to receive UU by US mail), and (5) the correct
amount of United States dollars to the address listed at the end of this
manual.


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). Thank you very much!

For those familiar with the Internet Relay Chat (IRC): I use the nick "BenJos"
on IRC, so /msg'ing me on IRC is another way of contacting me.

For those who have known me a bit longer: Note that I have moved from the
Netherlands to the United States. Anything sent to my old address in the
Netherlands will probably still reach me, although it may take some time.
However, I kindly request you not to send anything to my old address anymore.

Ben Jos  Walbeehm        (Please get my first name right, it is "Ben Jos".)
P.O. Box 292061
Tampa, Florida 33687
United States of America
E-mail: [e-mail]  (Using my wife's account until I get my own.)