UNZIPSFX(1L)                                         UNZIPSFX(1L)

       unzipsfx  -  self-extracting  stub  for  prepending to ZIP

       <name  of  unzipsfx+archive  combo>  [-cfptuz[ajnoqsCLV$]]
       [file(s) ... [-x xfile(s) ...]]

       unzipsfx is a modified version of unzip(1L) designed to be
       prepended to existing ZIP archives in order to form  self-
       extracting archives.  Instead of taking its first non-flag
       argument to be the zipfile(s) to  be  extracted,  unzipsfx
       seeks  itself  under  the name by which it was invoked and
       tests or extracts the contents of  the  appended  archive.
       Because  the executable stub adds bulk to the archive (the
       whole purpose of which is to be as small as  possible),  a
       number  of  the  less-vital  capabilities in regular unzip
       have been removed.  Among these are the  usage  (or  help)
       screen,  the listing and diagnostic functions (-l and -v),
       the ability to decompress older compression  formats  (the
       ``reduce,''  ``shrink''  and ``implode'' methods), and the
       ability to extract to a directory other than  the  current
       one.  Decryption is supported as a compile-time option but
       should be avoided unless  the  attached  archive  contains
       encrypted files.

       Note  that self-extracting archives made with unzipsfx are
       no more (or less) portable across different operating sys-
       tems  than  is  the unzip executable itself.  In general a
       self-extracting archive made on a particular Unix  system,
       for  example, will only self-extract under the same flavor
       of Unix.  Regular unzip may still be used to  extract  the
       embedded  archive  as with any normal zipfile, although it
       will generate a harmless warning about extra bytes at  the
       beginning  of  the  zipfile.   Despite  this, however, the
       self-extracting archive is technically  not  a  valid  ZIP
       archive,  and PKUNZIP may be unable to test or extract it.
       This limitation is due to the simplistic manner  in  which
       the  archive  is created; the internal directory structure
       is not updated to reflect the extra bytes prepended to the
       original zipfile.

              An  optional  list  of  archive  members to be pro-
              cessed.  Regular expressions (wildcards) similar to
              those  in Unix egrep(1) may be used to match multi-
              ple members.  These wildcards may contain:

              *      matches a sequence of 0 or more characters

              ?      matches exactly 1 character

              [...]  matches any single  character  found  inside
                     the  brackets;  ranges  are  specified  by a
                     beginning character, a hyphen, and an ending
                     character.   If  an  exclamation  point or a
                     caret (`!' or `^') follows the left bracket,
                     then  the  range  of  characters  within the
                     brackets is complemented (that is,  anything
                     except the characters inside the brackets is
                     considered a match).

              (Be sure to quote any character that  might  other-
              wise  be  interpreted  or modified by the operating
              system, particularly under Unix and VMS.)

       [-x xfile(s)]
              An optional list of archive members to be  excluded
              from  processing.   Since wildcard characters match
              directory separators (`/'), this option may be used
              to  exclude  any  files that are in subdirectories.
              For example, ``foosfx *.[ch] -x */*'' would extract
              all  C source files in the main directory, but none
              in any subdirectories.  Without the -x option,  all
              C  source  files in all directories within the zip-
              file would be extracted.

       If unzipsfx is compiled with SFX_EXDIR defined,  the  fol-
       lowing option is also enabled:

       [-d exdir]
              An  optional  directory  to which to extract files.
              By default, all files and subdirectories are recre-
              ated in the current directory; the -d option allows
              extraction in an arbitrary directory (always assum-
              ing  one has permission to write to the directory).
              The option and directory may be concatenated  with-
              out  any  white  space  between them, but note that
              this may cause normal shell  behavior  to  be  sup-
              pressed.    In   particular,  ``-d ~''  (tilde)  is
              expanded by Unix C shells  into  the  name  of  the
              user's  home directory, but ``-d~'' is treated as a
              literal subdirectory ``~'' of  the  current  direc-

       unzipsfx supports the following unzip(1L) options:  -c and
       -p (extract to standard output/screen), -f and -u (freshen
       and  update  existing  files  upon  extraction),  -t (test
       archive) and -z (print archive comment).  All normal list-
       ing  options  (-l,  -v  and -Z) have been removed, but the
       testing option (-t) may be used as a ``poor man's''  list-
       ing.    Alternatively,   those   creating  self-extracting
       archives may wish to include a short listing in  the  zip-
       file comment.

       See  unzip(1L)  for  a  more complete description of these

       unzipsfx currently supports all unzip(1L)  modifiers:   -a
       (convert  text files), -n (never overwrite), -o (overwrite
       without prompting), -q (operate quietly), -C (match  names
       case-insenstively), -L (convert uppercase-OS names to low-
       ercase), -j (junk paths) and -V (retain version  numbers);
       plus  the following operating-system specific options:  -X
       (restore VMS owner/protection info), -s (convert spaces in
       filenames  to underscores [DOS, OS/2, NT]) and -$ (restore
       volume label [DOS, OS/2, NT, Amiga]).

       (Support for regular ASCII text-conversion may be  removed
       in  future  versions,  since  it  is simple enough for the
       archive's creator to  ensure  that  text  files  have  the
       appropriate  format  for  the local OS.  EBCDIC conversion
       will of course continue to be supported since the  zipfile
       format implies ASCII storage of text files.)

       See  unzip(1L)  for  a  more complete description of these

       unzipsfx uses the same environment variables as  unzip(1L)
       does,  although this is likely to be an issue only for the
       person creating and testing the  self-extracting  archive.
       See unzip(1L) for details.

       Decryption  is supported exactly as in unzip(1L); that is,
       interactively with a  non-echoing  prompt  for  the  pass-
       word(s).   See  unzip(1L)  for  details.  Once again, note
       that if the archive has no encrypted  files  there  is  no
       reason  to  use a version of unzipsfx with decryption sup-
       port; that only adds to the size of the archive.

       To create a self-extracting archive letters from a regular
       zipfile  letters.zip  and change the new archive's permis-
       sions to be world-executable under Unix:

           cat unzipsfx letters.zip > letters
           chmod 755 letters
           zip -A letters

       To create the same archive under MS-DOS, OS/2 or NT  (note
       the use of the /b [binary] option to the copy command):

           copy /b unzipsfx.exe+letters.zip letters.exe
           zip -A letters.exe

       Under VMS:

           copy unzipsfx.exe,letters.zip letters.exe
           letters == "$currentdisk:[currentdir]letters.exe"
           zip -A letters.exe

       (The VMS append command may also be used.  The second com-
       mand installs the new program  as  a  ``foreign  command''
       capable  of taking arguments.  The third line assumes that
       Zip is already installed as  a  foreign  command.)   Under

           MakeSFX letters letters.zip UnZipSFX

       (MakeSFX  is  included  with the UnZip source distribution
       and with Amiga binary distributions.  ``zip  -A''  doesn't
       work  on  Amiga  self-extracting  archives.)   To test (or
       list) the newly created self-extracting archive:

           letters -t

       To test letters quietly, printing only a  summary  message
       indicating whether the archive is OK or not:

           letters -tqq

       To  extract  the complete contents into the current direc-
       tory, recreating all files and  subdirectories  as  neces-


       To extract all *.txt files (in Unix quote the `*'):

           letters *.txt

       To extract everything except the *.txt files:

           letters -x *.txt

       To  extract  only  the README file to standard output (the

           letters -c README

       To print only the zipfile comment:

           letters -z

       The principle and fundamental limitation  of  unzipsfx  is
       that  it is not portable across architectures or operating
       systems, and therefore neither are the resulting archives.
       For  some architectures there is limited portability, how-
       ever (e.g., between some flavors of Intel-based Unix).

       Another problem with the current  implementation  is  that
       any archive with ``junk'' prepended to the beginning tech-
       nically is no longer a zipfile (unless zip(1) is  used  to
       adjust the zipfile offsets appropriately, as noted above).
       unzip(1) takes note of the  prepended  bytes  and  ignores
       them  since  some  file-transfer protocols, notably MacBi-
       nary, are  also  known  to  prepend  junk.   But  PKWARE's
       archiver  suite  may not be able to deal with the modified
       archive unless its offsets have been adjusted.

       unzipsfx has no knowledge of the user's PATH, so  in  gen-
       eral  an  archive  must either be in the current directory
       when it is invoked, or else a full or relative  path  must
       be  given.  If a user attempts to extract the archive from
       a directory in  the  PATH  other  than  the  current  one,
       unzipsfx  will print a warning to the effect, ``can't find
       myself.''  This is always true under Unix and may be  true
       in some cases under MS-DOS, depending on the compiler used
       (Microsoft C fully qualifies the program name,  but  other
       compilers  may  not).  Under OS/2 and NT there are operat-
       ing-system calls available  that  provide  the  full  path
       name,  so  the archive may be invoked from anywhere in the
       user's path.  The situation is  not  known  for  AmigaDOS,
       Atari TOS, MacOS, etc.

       As noted above, a number of the normal unzip(1L) functions
       have been removed  in  order  to  make  unzipsfx  smaller:
       usage  and  diagnostic info, listing functions and extrac-
       tion to other directories.  Also, only stored and deflated
       files are supported.  The latter limitation is mainly rel-
       evant to those who create SFX archives, however.

       VMS users must know how to set up self-extracting archives
       as  foreign  commands  in  order  to use any of unzipsfx's
       options.  This is not necessary for simple extraction, but
       the  command  to do so then becomes, e.g., ``run letters''
       (to continue the examples given above).

       unzipsfx on the Amiga requires the use of a  special  pro-
       gram,  MakeSFX, in order to create working self-extracting
       archives; simple concatenation does not work.  (For  tech-
       nically oriented users, the attached archive is defined as
       a ``debug hunk.'')  There may  be  compatibility  problems
       between the ROM levels of older Amigas and newer ones.

       All current bugs in unzip(1L) exist in unzipsfx as well.

       unzipsfx's  exit status (error level) is identical to that
       of unzip(1L); see the corresponding man page.

       funzip(1L), unzip(1L), zip(1L), zipcloak(1L), zipgrep(1L),
       zipinfo(1L), zipnote(1L), zipsplit(1L)

       The     Info-ZIP     home    page    is    currently    at
       http://www.cdrom.com/pub/infozip/ .

       Greg Roelofs was responsible for the  basic  modifications
       to  UnZip necessary to create UnZipSFX.  See unzip(1L) for
       the current list of Zip-Bugs authors, or the file CONTRIBS
       in  the  UnZip  source  distribution  for the full list of
       Info-ZIP contributors.

Info-ZIP             28 November 1998 (v5.4)                    1