UUDEVIEW
Section: User Commands (1)
Updated: December 1996
NAME
uudeview - a powerful decoder for binary files
SYNOPSIS
uudeview [-i] [-d] [-f] [-o] [-b1] [-t] [(+e|-e) extlist]
[-v] [-s] [-m] [-n] [-p path] [@file] file(s)
DESCRIPTION
uudeview
decodes files that you have received in encoded form via electronic mail
or from the usenet, similar to the standard
uudecode(1)
command, yet with more comfort and flexibility.
uudeview
supports the
uuencoding, xxencoding, Base64
and
BinHex
encoding methods, and is able to handle split-files (which have been sent
in multiple parts) as well as multiple files at once, thus greatly simplifying
the decoding process. Usually, you will not have to manually edit files to
prepare them for decoding.
After invoking
uudeview,
it will scan all given files for encoded data, sort them and their parts
and then present you with the list of files that seem like they can be
decoded properly. You can then pick files individually for decoding.
OPTIONS
- -i
-
Disables interactivity. After scanning the files and sorting everything out,
the program will not ask for whether a file shall be decoded or not, but
immediately batch-decodes everything possible.
- -d
-
Sets the program into desperate mode. It will then offer you to decode
incomplete files. This is useful if you are missing the last part of a
50-parts posting, but in most cases the desperately-decoded files will
simply be corrupt and unusable. The degree of usefulness of an incomplete
file depends on the file type.
- -f
-
Uses fast mode for file scanning. The program assumes that each input file
holds at most one part, which is usually true for files in a news spool
directory. This option
breaks decoding
of input files with multiple articles. Also, certain sanity checks are
disabled, probably causing erroneous files to be presented for decoding.
Sometimes you'll get error messages when decoding, sometimes you'll
just receive invalid files. Don't use
-f
if you can't live with these problems.
- -o
-
Gives the OK to overwrite existing files when decoding. The default is
to prompt the user whether to overwrite, rename or skip the file.
- -v
-
Disables
verbosity. Normally, the program prints some status messages
while reading the input files, which can be very helpful if something
should go wrong. Use if these messages disturb you.
- -p path
-
Sets the path where decoded files shall be written to. This must be a valid
pathname, or you'll get errors when trying to decode anything. Defaults to
the current working directory.
- +e exts
-
Selects only the files with the given extensions for decoding, others will
be ignored.
+e .gif.jpg
would decode all gif and jpeg files, but not tif or other files. The
list of extensions works case-insensitive.
- -e exts
-
The reverse of the above.
You will experience unwanted results if you try to mix +e and -e options
on the command line.
- -b1
-
This changes
uudeview's
policy of finding a part number on a subject line and may only be needed
in some rare cases when part numbers are found in () parentheses as well
as in [] brackets, for example in a series of multi-part postings. By
default,
uudeview
uses the numbers found in () parentheses first. But if this number indicates
the file's number in the series and the part number is given in [] brackets,
use this parameters to make the program read the other number first. This
does not affect decoding of files with only one or neither type of brackets.
If you prefer, you can also use the option as
-b[]
- -s
-
Read "minus smartness". This option turns off automatic part number
detection from the subject line. Try this option if
uudeview
fails to parse the subject line correctly and makes errors at guessing
part numbers, resulting in incorrect ordering of the parts. With this
option, parts are always put together sequentially (so the parts must
be correctly ordered in the input file). Also, with this option, the
program cannot detect that parts are missing.
Note:
The correct part number found in proper
MIME
files is still evaluated.
If this option is given twice, the subject itself is ignored, too, and
won't be used to group parts. Use if the messages that the parts come
delivered in have different subject lines.
- -m
-
Ignore file mode. uuencoded and xxencoded files have the original file
permissions stored on the begin line. If this option is not given, the
decoder tries to restore them. With this option, the resulting permissions
will always be 0666 minus your umask.
- -n
-
No progress bars. Normally, UUDeview prints ASCII bars crawling up
to 100 percent, but does not check if your terminal is capable of
displaying them. Use this switch if your terminal isn't, or if you
find the bars annoying.
- -t
-
Use plaintext messages. Usually, uudeview only presents encoded data
for decoding. With this option set, text parts from
MIME
messages and non-encoded messages are also offered. Plaintext messages
frequently don't have an associated filename, so they're assigned a
unique name from a sequential four-digit number.
- file(s)
-
The files to be scanned for encoded files. You can also give a single hyphen
'-' to read from standard input. Any number of files may be given, but
there is usually a limitation of 128 options imposed by the shell. If you are
composing the list of files with wildcards, make sure you don't accidentally
feed the program with binary files. This will result in undefined behaviour.
- @file
-
Makes
uudeview
read further options from the file. Each line of the file must hold exactly
one option. The file
is erased
after the program finishes. This feature may be used to specify an unlimited
number of files to be scanned. Combined with the powers of
find(1),
entire directory trees (like the news spool directory) can be processed.
Options may also be set in the $UUDEVIEW environment variable, which is
read before processing the options on the command line.
DECODING
After all input files have been scanned, you are asked for each file what
do do with it. Of course, the usual answer is to decode it, but there are
other possibilities. You can use the following commands (each command is
a single letter):
- d
-
(D)ecode the file and write the decoded file to disk, with the given name.
- y
-
(Y)es does the same as (d).
- x
-
E(x)tract also decodes the file.
- n
-
Skips this file without decoding it.
- b
-
Steps back to the previous file.
- i
-
Displays info about the file, if present. If a multipart posting had a
zeroeth part, it is printed, otherwise the first part up to the encoded
data is printed.
- e
-
Execute a command. You can enter any arbitrary command, possibly using the
current file as an argument. All dollar signs '$' in this command line are
replaced with the filename of the current file (speaking correctly, the name
of a temporary file). You should not background processes using this
temporary file, as programs might get confused if their input file suddenly
disappears.
- l
-
List a file. Use this command only if you know that the file in question is
a textfile, otherwise, you'll get a load of junk.
- r
-
Rename. You can choose a different name for the file in order to save it
under this new name.
- p
-
Set the path where decoded files shall be written to. This path can also
be set with the -p command line option.
- q
-
Quits the program immediately.
- ?
-
Prints a short description of all these commands.
If you don't enter a command and simply hit return at the prompt, the
default command, decoding the file, is used.
RUNTIME MESSGAGES
In verbose mode (that is, if you didn't disable verbosity with the
-v option), progress messages will appear.
They are extremely helpful in tracing what the program does, and can
be used to figure out the reason why files cannot be decoded, if you
understand them. This section explains how to interpret them.
Understanding this section is not essential to operate the program.
First, there are "Loading" messages, which begin with the string
"Loaded". Each line should feature the following items:
- Source File
-
The first item is the source file from which a part was loaded. Many
parts can be detected within a single file.
- Subject Line
-
The complete subject is reproduced in single quotes.
- Identifier
-
The program derives a unique identification for this thread from the
subject line, for grouping articles that look like they belong to the
same file. The result of this algorithm is presented in braces.
- Filename
-
If a filename was detected on the subject line or within the data (for
example, on a begin line, or as part of the Content-Type information).
- Part Number
-
The part number derived from the subject line, or, in the case of
properly MIME-formatted messages, from the "part" information.
- Begin/End
-
If a "begin" or "end" token was detected, it is printed here.
- Encoding Type
-
If encoded data was detected within this part, either "UUdata",
"Base64", "XXdata" or "Binhex" is printed here.
More messages are printed after scanning has completed. A single line
will be printed for each group of articles. The contents of this line
are best understood by looking at an example. Here is one:
Found 'mailfile.gz' State 16 UUData Parts begin 1 2 3 4 5 end 6 OK
This indicates that the file
mailfile.gz
has been found. The file was uuencoded ("UUData") and consists of
6 parts. The "begin" token was found in the first part, and the
"end" token was found in the sixth part. Because it looks like
everything's there, this file is tagged as being "OK". The
State
is a set of bits, where the following values may be or'ed:
- 1
-
Missing Part
- 2
-
No Begin
- 4
-
No End
- 8
-
No encoded data found.
- 16
-
File looks Ok
- 32
-
An error occured during decoding of the file.
- 64
-
File was successfully decoded.
NOTES
Because the program cannot receive terminal input when reading from standard
input, the interactivity is automatically disabled in this case.
When MIME-style message headers are detected, the program behaves nearly
MIME-compliant.
Nearly,
because the standard does not allow a file to hold more than one messages,
but
uudeview
works without this restrictions. Actually, if you guarantee this condition
using the
-f
command line switch, the program fully complies to RFC1521.
(Even with this switch set, all parts of a proper MIME multipart message
are handled.)
The scanner tends to ignore short Base64 data (less than four lines)
outside of MIME messages. Some checks for this condition are used in
desperate mode, but they may cause misdetection of encoded data,
resulting in some invalid files.
Files are always decoded into a temporary file first, then this file is copied
to the final location. This is to prevent accidentally overwriting existing
files with data that turns out too late to be undecodeable. Thus be careful
to have twice the necessary space available. Also, when reading from
standard input, all the data is dumped to a temporary file before
starting the usual scanning process on that file.
uudeview
tries to derive all necessary information from the Subject: line if present.
If it holds garbage, or if the program fails to find a unique identification
and the part number there,
uudeview
might still be able to decode the file using other heuristics, but you'll
need major luck then.
Yet this is only a concern with split-files. If all encoded files only consist
of single parts, don't worry.
If you rename, copy or link the program to
uudecode,
it may act as a smart replacement for the standard, accepting the same
command-line options. This has not been well-tested yet.
SEE ALSO
uuenview(1),
uudecode(1),
uuencode(1),
The
uudeview
homepage on the Web,
http://www.uni-frankfurt.de/~fp/uudeview/
BUGS
To read a file whose name starts with a hyphen '-', prepend a path
name, for example './'.
Before reporting a bug, make sure the file can be decoded by other means. I
hate to receive bug-reports where it turns out that
uudeview
just failed to decode complete garbage.
If you think you've found a bug, email the source file (at best,
compress and encode the original file, don't just include it) and
a listing of the program's messages (from verbose mode) to
fp@informatik.uni-frankfurt.de.
The checksums found in
BinHex
data are currently ignored.
The program cannot fully handle partial multipart messages (MIME-style
multipart messages split over several mail messages). The individual
parts are recognized and concatenated, and the embedded multipart
message is "decoded" into a plain-text file, which must then be fed
again to
uudeview.
Don't worry, these kinds of messages are rare.