


     UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))      XXXXEEEENNNNIIIIXXXX 3333....0000 ((((22228888 AAAAuuuugggg 99994444 ((((vvvv5555....11112222))))))))	  UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))



     NNNNAAAAMMMMEEEE
	  unzipsfx - self-extracting stub for prepending to ZIP
	  archives

     SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
	  <<<<nnnnaaaammmmeeee	ooooffff uuuunnnnzzzziiiippppssssffffxxxx++++aaaarrrrcccchhhhiiiivvvveeee ccccoooommmmbbbboooo>>>> [----ccccffffppppttttuuuuzzzz[aaaajjjjnnnnooooqqqqssssCCCCLLLLVVVV$$$$]]
	  [_f_i_l_e(_s) ... [----xxxx _x_f_i_l_e(_s) ...]]

     DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
	  _u_n_z_i_p_s_f_x is a	modified version of _u_n_z_i_p(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, _u_n_z_i_p_s_f_x
	  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	regular	version's less-vital capabilities have
	  been removed.	 Among these are the usage (or help) screen,
	  the listing and diagnostic functions (----llll and ----vvv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.

	  NNNNooootttteeee tttthhhhaaaatttt sssseeeellllffff----eeeexxxxttttrrrraaaaccccttttiiiinnnngggg aaaarrrrcccchhhhiiiivvvveeeessss mmmmaaaaddddeeee wwwwiiiitttthhhh _u_n_z_i_p_s_f_x	aaaarrrreeee nnnnoooo
	  mmmmoooorrrreeee ((((oooorrrr lllleeeessssssss)))) ppppoooorrrrttttaaaabbbblllleeee aaaaccccrrrroooossssssss ddddiiiiffffffffeeeerrrreeeennnntttt ooooppppeeeerrrraaaattttiiiinnnngggg ssssyyyysssstttteeeemmmmssss
	  tttthhhhaaaannnn iiiissss tttthhhheeee _u_n_z_i_p eeeexxxxeeeeccccuuuuttttaaaabbbblllleeee iiiittttsssseeeellllffff....	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 _u_n_z_i_p 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.

     AAAARRRRGGGGUUUUMMMMEEEENNNNTTTTSSSS
	  [_f_i_l_e(_s)]
	       An optional list	of archive members to be processed.
	       Regular expressions (wildcards) similar to those	in
	       Unix _e_g_r_e_p(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



     Page 1					     (printed 3/25/95)






     UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))      XXXXEEEENNNNIIIIXXXX 3333....0000 ((((22228888 AAAAuuuugggg 99994444 ((((vvvv5555....11112222))))))))	  UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))



		    an exclamation point or a caret (`!' or `^')
		    follows the	left bracket, then the range of
		    characters within the brackets is complemented
		    (that is, anything _e_x_c_e_p_t the characters inside
		    the	brackets is considered a match).

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

	  [----xxxx _x_f_i_l_e(_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 which 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xxx option, all C source
	       files in	all directories	within the zipfile would be
	       extracted.  Unlike in _u_n_z_i_p(1L),	the ----xxxx option may only
	       be used if one or more _f_i_l_e_s are	given.	This is
	       because there is	no zipfile separating the normal
	       options from the	----xxxx option, so _u_n_z_i_p_s_f_x sees it as
	       another normal option.  For historical reasons, the
	       ``normal'' ----xxxx is	silently ignored.  See the EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS
	       section below.

	  If _u_n_z_i_p_s_f_x is compiled with SFX_EXDIR defined, the
	  following option is also enabled:

	  [----dddd _e_x_d_i_r]
	       An optional directory to	which to extract files.	 By
	       default,	all files and subdirectories are recreated in
	       the current directory; the ----ddd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.
	       As with ----xxxx, the ----dddd option may only be used if one or
	       more _f_i_l_e_s are given.

     OOOOPPPPTTTTIIIIOOOONNNNSSSS
	  _u_n_z_i_p_s_f_x supports the	following _u_n_z_i_p(1L) options:  ----cccc and
	  ----pppp (extract to standard output/screen), ----ffff and ----uuuu (freshen
	  and update existing files upon extraction), ----tttt (test
	  archive) and ----zzzz (print archive comment).  All	normal listing
	  options (----llll, ----vvvv and ----ZZZZ) have been removed, but the testing
	  option (----tttt) may be used as a ``poor man's'' listing.



     Page 2					     (printed 3/25/95)






     UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))      XXXXEEEENNNNIIIIXXXX 3333....0000 ((((22228888 AAAAuuuugggg 99994444 ((((vvvv5555....11112222))))))))	  UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))



	  Alternatively, those creating	self-extracting	archives may
	  wish to include a short listing in the zipfile comment.

	  See _u_n_z_i_p(1L)	for a more complete description	of these
	  options.

     MMMMOOOODDDDIIIIFFFFIIIIEEEERRRRSSSS
	  _u_n_z_i_p_s_f_x currently supports all _u_n_z_i_p(1L) modifiers:	----aaaa
	  (convert text	files),	----nnnn (never overwrite), ----oooo (overwrite
	  without prompting), ----qqqq (operate quietly), ----CCCC (match names
	  case-insenstively), ----LLLL (convert uppercase-OS names to
	  lowercase), ----jjjj (junk paths) and ----VVVV (retain version numbers);
	  plus the following operating-system specific options:	 ----XXXX
	  (restore VMS owner/protection	info), ----sss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 _u_n_z_i_p(1L)	for a more complete description	of these
	  modifiers.

     EEEENNNNVVVVIIIIRRRROOOONNNNMMMMEEEENNNNTTTT OOOOPPPPTTTTIIIIOOOONNNNSSSS
	  _u_n_z_i_p_s_f_x uses	the same environment variables as _u_n_z_i_p(1L)
	  does,	although this is likely	to be an issue only for	the
	  person creating and testing the self-extracting archive.
	  See _u_n_z_i_p(1L)	for details.

     DDDDEEEECCCCRRRRYYYYPPPPTTTTIIIIOOOONNNN
	  Decryption is	supported exactly as in	_u_n_z_i_p(1L); that	is,
	  interactively	with a non-echoing prompt for the password(s).
	  See _u_n_z_i_p(1L)	for details.  Once again, note that if the
	  archive has no encrypted files there is no reason to use a
	  version of _u_n_z_i_p_s_f_x with decryption support; that only adds
	  to the size of the archive.

     EEEEXXXXAAAAMMMMPPPPLLLLEEEESSSS
	  To create a self-extracting archive _l_e_t_t_e_r_s from a regular
	  zipfile _l_e_t_t_e_r_s._z_i_p and change the new archive's permissions
	  to be	world-executable under Unix:

	      cat unzipsfx letters.zip > letters
	      chmod 755	letters

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




     Page 3					     (printed 3/25/95)






     UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))      XXXXEEEENNNNIIIIXXXX 3333....0000 ((((22228888 AAAAuuuugggg 99994444 ((((vvvv5555....11112222))))))))	  UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))



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

	  Under	VMS:

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

	  (The VMS _a_p_p_e_n_d command may also be used.  The second
	  command installs the new program as a	``foreign command''
	  capable of taking arguments.)	To test	(or list) the newly
	  created self-extracting archive:

	      letters -t

	  To test _l_e_t_t_e_r_s quietly, printing only a summary message
	  indicating whether the archive is OK or not:

	      letters -tq

	  To extract the complete contents into	the current directory,
	  recreating all files and subdirectories as necessary:

	      letters

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

	      letters *.txt

	  To extract everything	_e_x_c_e_p_t the *.txt _f_i_l_e_s:

	      letters *	-x *.txt

	  (Note	that with regular _u_n_z_i_p(1L) it would not be necessary
	  to use the first `*';	``unzip	letters	-x *.txt'' _w_o_u_l_d _w_o_r_k
	  _e_q_u_a_l_l_y _w_e_l_l.	 _W_i_t_h _u_n_z_i_p_s_f_x _t_h_e ----xxxx _o_p_t_i_o_n _w_o_u_l_d _b_e _s_i_l_e_n_t_l_y
	  _i_g_n_o_r_e_d _a_n_d _t_h_e _e_f_f_e_c_t _w_o_u_l_d _b_e _t_h_e _s_a_m_e _a_s _i_n _t_h_e _p_r_e_v_i_o_u_s
	  _e_x_a_m_p_l_e, _i._e., _t_h_e _o_p_p_o_s_i_t_e _o_f _w_h_a_t _w_a_s _i_n_t_e_n_d_e_d.) _T_o
	  _e_x_t_r_a_c_t _o_n_l_y _t_h_e _R_E_A_D_M_E _f_i_l_e _t_o _s_t_a_n_d_a_r_d _o_u_t_p_u_t (_t_h_e
	  _s_c_r_e_e_n):

	      letters -c README

	  To print only	the zipfile comment:

	      letters -z

     LLLLIIIIMMMMIIIITTTTAAAATTTTIIIIOOOONNNNSSSS
	  The principle	and fundamental	limitation of _u_n_z_i_p_s_f_x 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).



     Page 4					     (printed 3/25/95)






     UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))      XXXXEEEENNNNIIIIXXXX 3333....0000 ((((22228888 AAAAuuuugggg 99994444 ((((vvvv5555....11112222))))))))	  UUUUNNNNZZZZIIIIPPPPSSSSFFFFXXXX((((1111LLLL))))



	  _u_n_z_i_p_s_f_x 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, _u_n_z_i_p_s_f_x 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
	  which	provide	the full path name, so the archive may be
	  invoked from anywhere	in the user's path.  The situation is
	  not known for	Atari TOS, MacOS, etc.

	  As noted above, a number of the normal _u_n_z_i_p(1L) functions
	  have been removed in order to	make _u_n_z_i_p_s_f_x 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 _u_n_z_i_p_s_f_x'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).

	  _u_n_z_i_p_s_f_x is not supported on the Amiga because of the	way
	  the loader works; the	entire archive contents	would be
	  loaded into memory by	default.  It may be possible to	work
	  around this by defining the attached archive to be a ``debug
	  hunk,'' but compatibility problems between the ROM levels of
	  older	Amigas and newer ones are likely to cause problems
	  regardless.

	  All current bugs in _u_n_z_i_p(1L)	exist in _u_n_z_i_p_s_f_x as well.

     DDDDIIIIAAAAGGGGNNNNOOOOSSSSTTTTIIIICCCCSSSS
	  _u_n_z_i_p_s_f_x's exit status (error	level) is identical to that of
	  _u_n_z_i_p(1L); see the corresponding man page.

     SSSSEEEEEEEE AAAALLLLSSSSOOOO
	  _f_u_n_z_i_p(1L), _u_n_z_i_p(1L), _z_i_p(1L), _z_i_p_c_l_o_a_k(1L),	_z_i_p_g_r_e_p(1L),
	  _z_i_p_i_n_f_o(1L), _z_i_p_n_o_t_e(1L), _z_i_p_s_p_l_i_t(1L)

     AAAAUUUUTTTTHHHHOOOORRRRSSSS
	  Greg Roelofs was responsible for the basic modifications to
	  UnZip	necessary to create UnZipSFX.  See _u_n_z_i_p(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.




     Page 5					     (printed 3/25/95)



