Provided by: unzip_6.0-25ubuntu1_amd64 bug


       unzipsfx - self-extracting stub for prepending to ZIP archives


       <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 ability 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.   Similarly,  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
       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  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 `^') 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 otherwise 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 zipfile
              would be extracted.

       If unzipsfx is compiled with SFX_EXDIR defined, the following 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 permission  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.
       Alternatively, 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 options.


       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
       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(1) for a more complete description of these modifiers.


       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
       following format:

       $AUTORUN$>[command line string]

       When  unzipsfx  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
       character) is passed as a shell command to the operating system using the C rtl ``system''
       function. Before executing the command, unzipsfx 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 additional  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 and  change
       the new archive's permissions to be world-executable under Unix:

       cat unzipsfx > 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 letters.exe
       zip -A letters.exe

       Under VMS:

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

       (The VMS append command may also be used.  The second command 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 AmigaDOS:

       MakeSFX letters 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 screen):

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

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


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