home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / robot-pd / 22300.ZIP / 22300B.DSK / usage20.doc < prev    next >
Text File  |  1998-05-08  |  13KB  |  251 lines
  1. -----------------------CRLZH/UNCRLZH v2.0 Usage----------------------------
  2.  
  3. Since CRLZH and UNCRLZH are spawned from Steve Greenberg's CRUNCH and 
  4. UNCRunch V2.8, usage is exactly the same with the notable exceptions of the 
  5. file extensions used (LZH uses a 'Y' instead of a 'Z') and file limit of 256 
  6. rather than 512.  So...to avoid duplication, merely substitute CRLZH for 
  7. CRUNCH, UNCRLZH for UNCR and 2.0 for 2.8 in the following duplication of the 
  8. CRUNCH/UNCR usage notes:
  9.  
  10. -------------------CRUNCH/UNCRunch v2.8 Usage follows:---------------------
  11.  
  12.                          CRUNCH and UNCR
  13.                            Version 2.8
  14.  
  15.              Copyright (c) 1987 by Steven Greenberg
  16.    This Version Released with the Permission of the Author by
  17.                           Gene Pizzetta
  18.                            May 5, 1991
  19.  
  20.  
  21. CRUNCH and UNCR are basic file compression and decompression 
  22. tools for ZCPR3 and CP/M.  A number options allow these utilities 
  23. to serve as hard disk backup and restoral tools, and make CRUNCH 
  24. a convenient tool for creating of archival libraries.  UNCR 
  25. handles crunched, squeezed, and LZH-encoded files.
  26.  
  27. Under ZSDOS and ZDDOS file date stamps are embedded in the 
  28. crunched file and then restored to disk when the file is 
  29. uncrunched.  In addition, the source file's date stamp is 
  30. transferred to the crunched file's on-disk date stamp so the 
  31. create and modify dates can be checked without uncrunching it.
  32.  
  33. CRUNCH USAGE:
  34.  
  35.      CRUNCH {dir:}afn.aft {dir:} {[text]} {/options}
  36.  
  37. UNCR USAGE:
  38.  
  39.      UNCR {dir:}afn.aft {dir:} {/options}
  40.  
  41. All command line parameters are optional, except the source 
  42. filename, which may be ambiguous.  The output filename is 
  43. generated automatically.
  44.  
  45. The two DIR specifications, the first for the source file and the 
  46. second for the destination file, may be in DU (drive and user) 
  47. form or, if running under ZCPR3, named directories.  If no drive 
  48. or user is given, the current default directory is assumed.  
  49. Under ZCPR3 all 32 user areas are available, but only the first 
  50. 16 users are accessible under vanilla CP/M.
  51.  
  52. "[text]" is an optional text string (CRUNCH only) that can be 
  53. used to identify the file.  The text string must be enclosed with 
  54. square brackets.  During uncrunching UNCR will print on the 
  55. screen any text string contained in the crunched file.
  56.  
  57. OPTIONS:  The option list must be preceded by a slash and contain 
  58. no embedded spaces.
  59.  
  60.      A    Archive mode (CRUNCH only).  The only files crunched 
  61.           (or copied) are those that have been modified since 
  62.           they were last backed up, based on the archive 
  63.           attribute.  After each source file is crunched, its 
  64.           attribute will be changed to archived.  This option 
  65.           allows CRUNCH to be used as an simple archival backup 
  66.           tool.
  67.  
  68.      C    Confirm mode.  Same as I.
  69.  
  70.      E    Erase existing files without asking.  Suppresses the 
  71.           prompt "Erase existing file (Y/[N])?" when a file of 
  72.           the same name is found in the destination directory.  
  73.           Instead existing files will be erased and overwritten 
  74.           without notice.
  75.  
  76.      I    Inspect mode.  Allows choosing the files to be 
  77.           processed interactively.  Each filename is displayed, 
  78.           one at a time, alphabetically, and can be tagged for 
  79.           processing, untagged if tagged previously, or skipped.  
  80.           Processing begins after selection is completed.  This 
  81.           mode works similarly to the SWEEP and NSWP tagging 
  82.           concept.
  83.  
  84.      O    Overwrite mode.  Same as E.
  85.  
  86.      Q    Quiet mode.  Suppresses continuous console output 
  87.           during the processing of a file.  Only the input and 
  88.           output filenames and sizes in kilobytes will be 
  89.           displayed.  Normally this mode uses only one screen 
  90.           line for each file, so it allows the display of as many 
  91.           as 24 filename pairs at one time.  This mode is also 
  92.           desirable for printing or other slow terminals because 
  93.           they will slow down file processing.
  94.  
  95.      S    Include system files.  Allows system (hidden) files to 
  96.           be found and processed.  Normally system files are 
  97.           ignored.
  98.  
  99.      T    Tag mode.  Same as I.
  100.  
  101. All command line options can be set as the default mode of 
  102. operation (see "Configuration", below).  The command line option 
  103. will then toggle to the non-default mode.  The current effect of 
  104. the command line options is always correctly reflected by the 
  105. usage screen, which can be accessed by "CRUNCH //" or "UNCR //".
  106.  
  107. DETAILS:  CRUNCH and UNCR cannot handle more than 512 matching 
  108. files.  When system files are being ignored, such files do not 
  109. count toward this file limit.  In archive (option A) mode, 
  110. however, archived files still count, even though they will not be 
  111. processed, because this mode works internally by "tagging" all 
  112. files which do have their archive attribute set.  That method can 
  113. be useful, however, because if inspect mode (options I or T) is 
  114. also selected, all filenames are presented as if inspect mode had 
  115. been selected alone, except unarchived files will already be 
  116. tagged.  It is then possible to tag any archived files that you 
  117. might want to include, or to untag any pre-tagged unarchived 
  118. files you might want to skip.
  119.  
  120. Pressing ^C will abort either program immediately.  It may be 
  121. issued anytime the programs are running.  The partial output file 
  122. will be closed and erased, so zero-length files or files in an 
  123. unknown condition will not be left on the disk.  Although 
  124. probably of limited usefulness, ^S will pause the programs and 
  125. any key (except ^C) will resume operation.  Pressing ^C after a 
  126. ^S will abort the program, but a partial file will not be erased.
  127.  
  128. While crunching or uncrunching a file (unless in quiet mode) a 
  129. full running progress report is displayed, including the number 
  130. of input and output records, the compression ratio, the number of 
  131. codes assigned, and the number of codes reassigned.  Although 
  132. some of this information has limited usefulness, it is amusing to 
  133. watch.
  134.  
  135. OUTPUT FILENAMES:  The CRUNCH destination file will have the same 
  136. name as the crunched file, except that the middle letter of the 
  137. filetype will be changed to "Z".  If the source file's filetype 
  138. already has a "Z" as the middle letter, then the last two letters 
  139. of the filetype will be changed to "ZZ"  If the source file's 
  140. filetype already ends in "ZZ", or if its filetype is blank, then 
  141. "ZZZ" will be used as the filetype of the crunched file.  Files 
  142. with filetypes of "ZZZ" cannot be crunched.  When a file is 
  143. uncrunched by UNCR, its original filename and filetype will be 
  144. restored.
  145.  
  146. DIRECT COPYING:  If CRUNCH creates a file larger than the 
  147. original, this file will be automatically erased and replaced 
  148. with a direct copy of the original.  If the original is already 
  149. crunched or squeezed, or if the filetype matches a type on the 
  150. filetype exclusion list, such as .LBR or .ARK, no attempt will be 
  151. made to compress it.  Instead, a straight copy operation will be 
  152. substituted.  Thus all specified files will be transferred in the 
  153. most efficient manner, facilitating the use of CRUNCH for the 
  154. creation of LBR's or as a backup utility.  Similarly, UNCR will 
  155. either uncrunch or direct-copy all specified files for full 
  156. restoration.
  157.  
  158. If the source and destination directories are the same, then 
  159. direct copying is inhibited.  In this case, CRUNCH will ask the 
  160. user whether he wants to keep a crunched file, if it is larger 
  161. than the original.
  162.  
  163. LZH DECODING AND UNSQUEEZING:  UNCR also uncrunches LZH-encoded 
  164. files and unsqueezes as an added convenience.  The file's format 
  165. will be recognized automatically and the appropriate method will 
  166. be used.
  167.  
  168. EXCLUSION LIST OVERRIDE:  While it is useful to have CRUNCH skip 
  169. attempts to compress certain filetypes when doing bulk transfers, 
  170. there may be instances where you want to crunch, for instance, a 
  171. LBR file.  (As distributed, excluded filetypes are ARC, ARK, LBR, 
  172. and FOR.)  To make that possible, CRUNCH will ignore the filetype 
  173. exclusion list if a filename is fully specified.  The exclusion 
  174. list will be used, however, whenever one or more wildcard 
  175. characters ("?" or "*") appear in the filename.
  176.  
  177. SPANNING DISKETTES:  If an output disk fills during a wildcard 
  178. operation, the last (partial) file will be deleted and the user 
  179. will be prompted to change disks.  Operation will then continue, 
  180. starting  with that last file.  If the source and destination 
  181. drives are the same, however, then the prompt to change diskettes 
  182. will not be given, since changing the output diskette will remove 
  183. the input disk from which the program is reading.
  184.  
  185. UNCR WILDCARD LIMITATIONS:  Normally when UNCR is given a "*.*" 
  186. wildcard specification, it transfers all files from one drive 
  187. and/or user area to another, uncrunching crunched files, 
  188. unsqueezing squeezed files, and copying the rest.  If your intent 
  189. is to only process crunched files, you must issue a file 
  190. specification with a filetype of "?Z?".
  191.  
  192. When the source and destination directories are the same, 
  193. however, a file specification of "*.*" will be automatically 
  194. converted to "*.?Z?".  A side-effect is that squeezed and LZH- 
  195. encoded files will not be uncompressed unless a specific "*.?Q?" 
  196. or "*.?Y?" file specification is given.
  197.  
  198. FILE DATE STAMPS:  When running under ZSDOS or ZDDOS, CRUNCH will 
  199. store the date and time stamp of the source file in the header of 
  200. the crunched file.  In addition, it will transfer the source 
  201. file's date stamp to the crunched file's on-disk date stamp.  
  202. Since crunching is used primarily for archival storage and the 
  203. crunched file will not be modified in place, this latter feature 
  204. allows you to check the original date stamp of the file without 
  205. uncrunching it.  The access date of the crunched file will be the 
  206. date it was crunched, until you type it with ZLT or uncrunch it.
  207.  
  208. When UNCR uncrunches a file, it looks for a date stamp in the 
  209. header and, if it finds one, it restores the file's original 
  210. create and modify dates to the uncrunched file.  This restoral 
  211. works equally well with files crunched by CR23D.  If there is no 
  212. date stamp in the header of the crunched file, UNCR will transfer 
  213. the crunched file's on-disk date stamp to the uncrunched file, so 
  214. at least you will not lose whatever date stamp you have.  As with 
  215. CRUNCH, the access date will be the date the file is uncrunched.  
  216. The original access date is stored in the header by CRUNCH, but 
  217. it will not be restored.
  218.  
  219. If the source file has no modify date, a non-standard condition, 
  220. the modify date of the output file will be filled in from the 
  221. create date.  A blank create date will be transferred as is.
  222.  
  223. TELENET AND PC-PURSUIT SUPPORT:  CRUNCH monitors its output for a 
  224. sequence that would put Telenet or PC-Pursuit into command mode 
  225. and abort a file transfer.  If this sequence is detected, CRUNCH 
  226. inserts the CRUNCH null code to prevent disaster.
  227.  
  228. CONFIGURATION:  All the modes of operation set by command line 
  229. options can be configured as default modes.  In that case the 
  230. corresponding command line option will toggle to the non-default 
  231. mode.  (The current effect of the command line options will 
  232. always be reflected by the usage screen.)  In addition, CRUNCH 
  233. contains a list of filetypes that will be ignored during wildcard 
  234. operations.  Up to 10 filetypes can be entered in the list.  
  235. There are also specific options that are only effective under 
  236. TurboDos or vanilla CP/M.
  237.  
  238. Configuration for both CRUNCH and UNCR is accomplished using the 
  239. accompanying CRUNCHnn.CFG file and ZCNFG, which is available from 
  240. most Z-Nodes and RCP/M's.  The name of the configuration file 
  241. should not be changed.  More complete instructions are included 
  242. on the configuration help screens.
  243.  
  244. +---------------------------------------------------------------+
  245. | The source code, as well as any object code created from it,  |
  246. | are copyright (c) 1987 by Steven Greenberg.  It may be repro- |
  247. | duced for non-profit use only.  Public release of modifica-   |
  248. | tions is strictly prohibited without the expressed consent of |
  249. | the author.                                                   |
  250. +---------------------------------------------------------------+
  251.