Seth Woolley's Man Viewer

uudecode(1) - UUDeview - a powerful decoder for binary files - man 1 uudecode

([section] manual, -k keyword, -K [section] search, -f whatis)
man plain no title

UUDEVIEW(1)                                                        UUDEVIEW(1)

       UUDeview - a powerful decoder for binary files

       uudeview [options] [@file(1,n)] file(1,n)(s)

       UUDeview  is  a smart decoder for attachments that you have received in(1,8)
       encoded form via electronic mail(1,8) or from the usenet. It is  similar  to
       the  standard  uudecode(1) command, yet with more comfort and flexibil-
       ity.  UUDeview supports the uuencoding, xxencoding,  Base64,  yEncoding
       and  BinHex  encoding(3,n) methods, and is able to handle split-files (which
       have been sent in(1,8) 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(1,3)  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.

       -i     Disables  interactivity.  After  scanning  the files and sorting
              everything out, the program will not promt  you  for  whether  a
              file(1,n)  shall  be  decoded or not, but batch-decodes all available
              files.  This is the default when reading from standard input.

       -a     Autorename option. If a target file(1,n)  already  exists,  and  this
              option  is given, a dot and a unique sequence number is appended
              to the file(1,n) name.  I.e., foo.gif becomes foo.gif.1 if(3,n) decoded  a
              second time.

       +a     An  alternative  incarnation  of  autorename.  If  a target file(1,n)
              already exists, an underscore and a unique  sequence  number  is
              inserted  into  the filename before the first dot, i.e., foo.gif
              becomes foo_1.gif.

       -o     Gives the OK to  overwrite  existing  files  when  decoding.  In
              interactive  mode,  the default is to prompt the user whether to
              overwrite, rename(1,2,n) or skip the file. This option takes precedence
              over -a.  In non-interactive mode (using -f ), the default is to
              overwrite files without asking.

       +o     Says it's not OK to overwrite files.  This  is  useful  in(1,8)  non-
              interactive mode, so that existing files are untouched. This has
              lesser precedence than -a.

       -c     Autoclear.  Remove  all  input  files  that  were   successfully
              decoded.  Use  with  care!  UUDeview only checks if(3,n) any data was
              decoded from an input file(1,n), but does not care  about  any  other
              contents  of  that  input  file(1,n),  or whether a file(1,n) also held an
              incomplete attachment.

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

       -m     Ignore file(1,n) mode. Uuencoded and xxencoded files have the  origi-
              nal  file(1,n)  permissions  stored  on  the  begin line. Unless this
              option is given, UUDeview will restore them without checking  if(3,n)
              they  are  sensible. With this option, the permissions are reset(1,7,1 tput)
              to a default of 0666.

       -z     Enforces stricter MIME adherance. Normally, the program tries to
              find  encoded  data even in(1,8) "text/plain" plaintext parts of MIME
              messages. With this option given, UUDeview will limit this capa-
              bility,  and  will not accept(2,8) apparently incomplete encoded mes-
              sages (for example, seemingly uuencoded data  without  begin  or
              end  lines).   You can tighten this option even more by using it
              twice, or by using -z2.  Then, UUDeview will not check plaintext
              sections  of  MIME  messages  for encoded data at all and behave
              fully MIME-compliant.  Neither option affects  the  behavior  on
              non-MIME  input  files. This option needs a better name, but I'm
              slowly running out of option letters.

       -f     Uses fast mode for file(1,n) scanning. The program assumes that  each
              input  file(1,n)  holds  at  most one part, which is usually true for
              files in(1,8) 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(8,n) messages when decod-
              ing, sometimes you'll just receive invalid files. Don't  use  -f
              if(3,n) you can't live with these problems.

       -r     Ignore  reply  messages,  i.e. all messages whose subject starts
              with Re:

       -t     Use plaintext messages. Usually, UUDeview only presents  encoded
              data  for  decoding.  Plaintext  messages are only shown if(3,n) they
              have an associated file(1,n) name. With this option set(7,n,1 builtins), unnamed text
              parts  from  MIME  messages  and  non-encoded  messages are also
              offered. Unnamed messages are assigned a unique name in(1,8) the form
              of a sequential four-digit number.

       -d     Sets  the program into desperate mode. It will then offer you to
              decode incomplete files. This is useful if(3,n) you are  missing  the
              last  part  of a 50-parts posting, but in(1,8) most cases the desper-
              ately-decoded files will simply be  corrupt  and  unusable.  The
              degree  of  usefulness of an incomplete file(1,n) depends on the file(1,n)

       -b     This changes UUDeview's "bracket policy."  UUDeview looks  at  a
              message's  subject  line,  and  reads numbers in(1,8) brackets as the
              part number, as in(1,8) (3/7), which is read(2,n,1 builtins) as the third message  in(1,8)
              a  series  of  seven.  By default, numbers in(1,8) parentheses () are
              preferred over numbers in(1,8) brackets []. You can change this using
              either -b or, for clarity -b[].

       -s     Read  "minus  smartness".  This  option turns off automatic part
              number detection from the subject line. Try this option if(3,n) UUDe-
              view  fails to parse the subject line correctly and makes errors
              at guessing part numbers, resulting in(1,8) incorrect ordering of the
              parts.  With  this option, parts are always put together sequen-
              tially (so the parts must be  correctly  ordered  in(1,8)  the  input
              file(1,n)).  Also,  with  this option, the program cannot detect that
              parts are missing.  Note:  The  correct  part  number  found  in(1,8)
              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(3,n) the messages that the parts come delivered
              in(1,8) have different subject lines.

       -q     (Quiet) Disables verbosity. Normally, the  program  prints  some
              status messages while reading the input files, which can be very
              helpful if(3,n) something should go wrong. Use if(3,n) these messages dis-
              turb you.

       -n     No  progress bars. Normally, UUDeview prints ASCII bars crawling
              up to 100 percent, but does not check if(3,n) your terminal is  capa-
              ble  of displaying them. Use this switch(1,n) if(3,n) your terminal isn't,
              or if(3,n) you find the bars annoying.

       +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(3,n)  you  try to mix +e and -e
       options on the command line.

              The files to be scanned for encoded files. You can also  give  a
              single  hyphen  -  to  read(2,n,1 builtins) 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(1,8) undefined behav-

       @file(1,n)  Makes UUDeview read(2,n,1 builtins) further options from the file. Each line  of
              the  file(1,n) must hold exactly one option. The file(1,n) is erased after
              the program finishes. This feature may be  used  to  specify  an
              unlimited  number of files to be scanned. Combined with the pow-
              ers of find(1), entire directory  trees  (like  the  news  spool
              directory) can be processed.

       Options may also be set(7,n,1 builtins) in(1,8) the $UUDEVIEW environment variable, which is
       read(2,n,1 builtins) before processing the options on the command line.

       After all input files have been scanned, you are asked  for  each  file(1,n)
       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(1,n) and write(1,2) the decoded file(1,n) to disk, with the
              given name.

       y      (Y)es does the same as (d).

       x      E(x)tract also decodes the file.

       a      Decodes all remaining files without prompting.

       n      Skips this file(1,n) without decoding it.

       b      Steps back to the previous file.

       r      Rename. You can choose a different name for the file(1,n) in(1,8) 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(7,n,1 builtins) with the -p command line option.

       i      Displays info(1,5,n) about the file(1,n), if(3,n) 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(1,n) as an argument. All dollar signs '$' in(1,8)
              this command line are replaced with the filename of the  current
              file(1,n)  (speaking  correctly,  the  name of a temporary file(1,n)). You
              should not background processes using this  temporary  file(1,n),  as
              programs  might get confused if(3,n) their input file(1,n) suddenly disap-

       l      List a file. Use this command only if(3,n) you know that the file(1,n)  in(1,8)
              question is a textfile, otherwise, you'll get a load(7,n) of junk.

       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(1,n), is used.

       In verbose mode (that is, if(3,n) you didn't disable verbosity with  the  -v
       option),  progress messages will appear.  They are extremely helpful in(1,8)
       tracing what the program does, and can be used to figure out the reason
       why  files  cannot  be  decoded,  if(3,n)  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(3,n)
       "Loaded". Each line should feature the following items:

       Source File
              The first item is the source file(1,n) from which a part was  loaded.
              Many parts can be detected within a single file.

       Subject Line
              The complete subject is reproduced in(1,8) single quotes.

              The program derives a unique identification for this thread from
              the subject line, for grouping  articles  that  look(1,8,3 Search::Dict)  like  they
              belong  to  the  same file. The result of this algorithm is pre-
              sented in(1,8) braces.

              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(1,8)  the  case
              of  properly  MIME-formatted  messages, from the "part" informa-

              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(1,n) mailfile.gz has been found. The file(1,n) was
       uuencoded ("UUData") and consists of 6 parts.  The  "begin"  token  was
       found  in(1,8)  the  first  part, and the "end" token was found in(1,8) the sixth
       part. Because it looks like everything's there, this file(1,n) is tagged  as
       being  "OK". The State is a set(7,n,1 builtins) 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(8,n) occured during decoding of the file.

       64     File was successfully decoded.

       Because the program cannot receive terminal input when a file(1,n) is  being
       read(2,n,1 builtins)  from  standard  input, interactivity is automatically disabled in(1,8)
       this case.

       UUDeview is aware of MIME messages, but normally  ignores  strict  MIME
       compliance  in(1,8)  favor  of  finding unproperly encoded data within them,
       e.g. to succeed when individual parts of a  uuencoded  file(1,n)  have  been
       sent  with  a  MIME  mailer as MIME messages. For that, it subjects all
       "text/plain" parts of a message to encoding(3,n) detection. You can use  the
       -z option (see above) for more strict RFC2045 compliance.

       The  scanner  tends  to ignore short Base64 data (less(1,3) than four lines)
       outside of MIME messages. Some checks for this condition  are  used  in(1,8)
       desperate  mode,  but  they  may  cause  misdetection  of encoded data,
       resulting in(1,8) some invalid files.

       Files are always decoded into a temporary file(1,n) first, then this file(1,n) is
       copied to the final location. This is to prevent accidentally overwrit-
       ing existing files with data that turns out too late  to  be  undecode-
       able.  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(1,n) before starting the usual scanning process on that file.

       uudeview tries to derive all necessary information  from  the  Subject:
       line  if(3,n) present.  If it holds garbage, or if(3,n) the program fails to find
       a unique identification and the part number there, uudeview might still
       be  able  to  decode  the  file(1,n) 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(1,2,n),  copy or link(1,2) 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.

       uuenview(1), uudecode(1), uuencode(1,5)(1).
       The UUDeview homepage on the Web,

       To  read(2,n,1 builtins)  a  file(1,n)  whose  name starts with a hyphen '-', prepend a path
       name, for example './'.

       The checksums found in(1,8) BinHex data are ignored.

       The program cannot fully handle partial multipart messages  (MIME-style
       multipart  messages  split(1,n)  over several mail(1,8) messages). The individual
       parts are recognized and concatenated, and the embedded multipart  mes-
       sage  is "decoded" into a plain-text file(1,n), which must then be fed again
       to uudeview.  Don't worry, these kinds of messages are rare.

       UUDeview cannot decipher RFC 1522 headers.

                                   June 2001                       UUDEVIEW(1)

References for this manual (incoming links)