Unix‎ > ‎Solaris‎ > ‎Solaris man pages‎ > ‎1‎ > ‎


     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(1)  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  abil-
     ity to decompress older compression formats (the ``reduce,''
     ``shrink'' and ``implode'' methods).  The ability to extract
     to a directory other than the current one can be selected as
     a compile-time option, which is now enabled by default since
     UnZipSFX  version 5.5.  Similary, decryption is supported as
     a compile-time option  but  should  be  avoided  unless  the
     attached  archive  contains  encrypted  files. Starting with
     release 5.5, another compile-time option adds a simple ``run
     command   after   extraction''  feature.   This  feature  is
     currently  incompatible  with  the  ``extract  to  different
     directory'' feature and remains disabled by default.

     Note that self-extracting archives made with unzipsfx are no
     more  (or  less) portable across different operating systems
     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 embed-
     ded archive as with any normal  zipfile,  although  it  will
     generate  a harmless warning about extra bytes at the begin-
     ning 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 limi-
     tation  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 zip-

          An optional list of archive members  to  be  processed.
          Regular  expressions  (wildcards)  similar  to those in
          Unix egrep(1) may be used to  match  multiple  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 `^') fol-
               lows the left bracket, then the range  of  charac-
               ters 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 otherwise be
          interpreted  or  modified by the operating system, par-
          ticularly 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 subdirec-
          tories.  Without the -x option, all C source  files  in
          all directories within the zipfile would be extracted.

     If unzipsfx is compiled with SFX_EXDIR defined, the  follow-
     ing option is also enabled:

     [-d exdir]
          An optional directory to which to  extract  files.   By
          default,  all files and subdirectories are recreated in
          the current directory; the -d option allows  extraction
          in an arbitrary directory (always assuming one has per-
          mission to write to the  directory).   The  option  and
          directory  may  be concatenated without any white space
          between them, but note that this may cause normal shell
          behavior  to  be  suppressed.   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 directory.

     unzipsfx supports the following unzip(1) 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 listing options
     (-l, -v and -Z) have been removed, but  the  testing  option
     (-t)  may  be  used  as  a ``poor man's'' listing.  Alterna-
     tively, those creating self-extracting archives may wish  to
     include a short listing in the zipfile comment.

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

     unzipsfx currently  supports  all  unzip(1)  modifiers:   -a
     (convert  text  files),  -n (never overwrite), -o (overwrite
     without prompting), -q (operate quietly),  -C  (match  names
     case-insensitively),   -L  (convert  uppercase-OS  names  to
     lowercase), -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  for-
     mat for the local OS.  EBCDIC conversion will of course con-
     tinue to be supported since the zipfile format implies ASCII
     storage of text files.)

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

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

     Decryption is supported exactly as  in  unzip(1);  that  is,
     interactively with a non-echoing prompt for the password(s).
     See unzip(1) 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 support; that only  adds
     to the size of the archive.

     When unzipsfx was compiled with CHEAP_SFX_AUTORUN defined, a
     simple  ``command  autorun''  feature  is supported. You may
     enter a command into the Zip archive comment, using the fol-
     lowing format:

         $AUTORUN$>[command line string]

     When unzipsfxP recognizes the ``$AUTORUN$>''  token  at  the
     beginning  of  the Zip archive comment, the remainder of the
     first line of the comment (until the first  newline  charac-
     ter)  is  passed  as a shell command to the operating system
     using the C rtl ``system'' function.  Before  executing  the
     command,  unzipsfxP  displays the command on the console and
     prompts the  user  for  confirmation.   When  the  user  has
     switched  off prompting by specifying the -q option, autorun
     commands are never executed.

     In case the archive  comment  contains  additonal  lines  of
     text,  the  remainder  of  the archive comment following the
     first line is displayed normally, unless quiet operation was
     requested by supplying a -q option.

     To create a self-extracting archive letters from  a  regular
     zipfile letters.zip and change the new archive's permissions
     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'' capa-
     ble of taking arguments.  The third line assumes that Zip is
     already installed as a foreign command.)  Under AmigaDOS:

         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 directory,
     recreating all files and subdirectories as necessary:


     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 sys-
     tems, and therefore neither are the resulting archives.  For
     some  architectures  there  is  limited portability, however
     (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 technically
     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 MacBinary, 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  general
     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 operating-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(1)  functions
     have  been removed in order to make unzipsfx smaller:  usage
     and diagnostic info, listing  functions  and  extraction  to
     other directories.  Also, only stored and deflated files are
     supported.  The latter  limitation  is  mainly  relevant  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 program,
     MakeSFX,   in   order   to  create  working  self-extracting
     archives; simple concatenation does not work.  (For  techni-
     cally  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(1) exist in unzipsfx as well.

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

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

     The Info-ZIP home page is currently at
         ftp://ftp.info-zip.org/pub/infozip/ .

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

     See attributes(5) for descriptions of the  following  attri-

    | Availability       |  SUNWswmt       |
    | Interface Stability|  External       |

     Source code of unzip is available on the Info-ZIP  project's
     page http://www.info-zip.org and is used without any modifi-

Man pages from Solaris 10 Update 8. See docs.sun.com and www.oracle.com for further documentation and Solaris information.