home *** CD-ROM | disk | FTP | other *** search
/ Oakland CPM Archive / oakcpm.iso / cpm / sysutl / egutil53.lbr / FINREP.DZC / FINREP.DOC
Encoding:
Text File  |  1988-07-12  |  14.4 KB  |  320 lines

  1. ;;12-22-87
  2.                      FINREP.DOC  Version 2.6
  3.                             01/02/88
  4.  
  5. Eric Gans
  6. French Department, UCLA
  7. Los Angeles, CA 90024
  8.  
  9.    * MS-DOS users: FINREP now exists for DOS. MS-DOS v2.4 is *
  10.    * (more or less) equivalent to CP/M v2.6.                 *
  11.  
  12. Version 2.6
  13. Corrected a bug in reading words across sectors.
  14.  
  15. Version 2.5
  16. Corrected a bug in the wild-card file routine (thanks to faithful 
  17. FINREP user John Stensvaag).  Improved verify routine (as per DOS 
  18. version); reduced program size.
  19.  
  20. Version 2.4
  21. The  search routines have been extensively revised and  debugged.  
  22. FINREP  should now find just about any string,  however perverse.  
  23.  
  24. Version 2.3
  25. Fixed  bug  that  made verification  incompatible  with  multiple 
  26. (wildcard)  files.   Allow wildcard (?,  not *) at end of  search 
  27. string.
  28.  
  29. Version 2.2
  30. Added  "V"  flag  to allow user verification  ("Replace  (y/n)?") 
  31. before replacement in text files; a few minor improvements.
  32.  
  33. Version 2.1
  34. Fixed bug that treated wildcard filetypes as single files.  Added 
  35. a couple of clarifications to DOC file.
  36.  
  37. Version 2.0
  38. Allows wildcard searches (various options),  wildcard  filetypes. 
  39. Easier entry of caps (!string!  instead of !s!t!r!i!n!g).  Allows 
  40. control characters other than letters (e.g., ^[,^@).
  41.  
  42.                               *****
  43.  
  44.      FINREP is a search/replace program that remedies most of the
  45. deficiencies of Wordstar's ^QA and other similar commands.  Aside
  46. from being faster, it has important additional features:
  47.  
  48.      - allows wildcards in search string (v2.0)
  49.      - allows wildcard filename (find/replace in groups of files)
  50.      - command-line entry allows batch processing by SUBMIT, etc.
  51.      - allows entry of control or hex characters (0-FF)
  52.      - can be used with object files (e.g., COM files)
  53.      - sets  capitalization (first letter or whole word) and high
  54.        bit of the last character according to the old string
  55.  
  56. This last feature means that,  for example,  if you are writing a 
  57. scenario where the characters' names appear sometimes in CAPS and 
  58. sometimes just Capitalized, you don't need two search/replaces to 
  59. replace one name with another: JOE will be replaced by HARRY, Joe 
  60. by Harry, and even joe by harry.  
  61.  
  62.                               *****
  63.  
  64. Format: finrep [d:]fn [newfn] /[switches]/ oldstring [newstring]
  65.  
  66. (Enter "finrep" alone for a brief command summary.)
  67.  
  68. If a second filename is given, the changes will be placed in that
  69. file;  if  not,  the  old filename will hold the changes and  the
  70. original  file will be changed from fn.ft to fn.BAK  (unless  the
  71. "B" switch is used).
  72.  
  73. Wildcards  (*,?) may be used anywhere in the filename;  if  there 
  74. are  wildcards in the filetype (after the ".") the B switch  will
  75. be  set  automatically  to suppress creation  of  BAK  files.  If 
  76. wildcards are used,  a second filename cannot be entered.  If you 
  77. enter:
  78.  
  79. A>finrep urk*.doc // "blurk" "zap"
  80.  
  81. the files urk01.doc,  urk33.doc,  urktty.doc would be modified as 
  82. expected and files urk01.bak, urk33.bak etc. would be created.
  83.  
  84. The characters "//" must be entered even if no switches are used.
  85.  
  86. The switches are as follows:
  87.  
  88. B  =  no BAK file.  This switch disables making a BAK  file;  the 
  89. original  file  will be lost.  (Use only if you did not  enter  a 
  90. second filename.)
  91.  
  92. Q = allow wildcards in search string. (The program runs faster if 
  93. this  switch is not used.)  The various options for this  command 
  94. are described below.
  95.  
  96. V = verify replacement.   If this switch is used,  the context of 
  97. the search string will be displayed on the screen and you will be 
  98. queried  re replacement.   This switch cannot be used along  with 
  99. the O or H switches (see below).
  100.  
  101. O = Object file.  If this switch is used, the program will ignore 
  102. end-of-file  markers (1AH),  as in PIP's "o"  command.   Use  for 
  103. search/replace in non-text files.   WARNING: if you don't use "O" 
  104. with  a  non-text  file it will be cut off after the  first  1AH. 
  105. That's why FINREP makes BAK files!
  106.  
  107. H  =  keep High bit.  With this switch,  all bytes  are  searched 
  108. exactly  as they are;  letters with the high bit set will not  be 
  109. identified  with their standard ASCII  counterparts.  
  110.  
  111. W = no Whole-word search.  This switch is used to search a string 
  112. whether  or not it is a whole word;  with it,  a search for "the" 
  113. will find "other", "their" etc.
  114.  
  115. NB  - The  program  defines a "word"  as  anything  preceded  and 
  116. followed  by  something other than a letter  (space,  punctuation 
  117. mark,  number, control character, beginning or end of file). Thus 
  118. this  switch  is not needed if the search string is a  series  of 
  119. words,  a  word  preceded  by a control  character  that  is  not 
  120. contiguous to another word, etc.
  121.  
  122. C  = respect case.  This switch allows you to distinguish capital 
  123. from lower-case letters: in a search for "the", "The" will not be 
  124. found/replaced.  (NB: Upper case letters cannot be entered within 
  125. quotes; see below.)
  126.  
  127.  
  128. In normal operation (with no switches),  the search will  include 
  129. whole words only; it will ignore case and high bits, but will set 
  130. the  new  string  to  correspond  to the  old  in  this  respect, 
  131. capitalizing the first letter or the whole string and setting the 
  132. high  bit  of the last as required.  This last  feature  is  only 
  133. useful if the replacement string is one word long; if it contains 
  134. more than one word,  you may set the high bits when you enter the 
  135. string,  or let your word-processor (e.g. Wordstar) do it. If you 
  136. include  capitals  in  your  replacement  string,  they  will  be 
  137. respected even if the find string is not capitalized.
  138.  
  139. If  you want to search for a capitalized word,  you must use  the 
  140. "C"  switch (or the "H" or "O" switch);  FINREP will give you  an 
  141. error message if you don't. 
  142.  
  143. The last four switches are in the relation O > H > C       
  144.                                                  > W  ; 
  145. the "higher" switch includes the smaller.  Thus if the "H" switch 
  146. is used,  capitals and lower case will be distinguished,  and the 
  147. search will not be limited to whole words.
  148.  
  149. *****************************************************************
  150.  
  151. String entry:
  152.  
  153. The  find  and replace strings must be separated by a space  from 
  154. the switch entry and from each other.  Strings should be  entered 
  155. as follows:
  156.  
  157. ASCII     - in quotes: "blurk", "54%**90er @"
  158.  
  159. The following characters must NOT be placed between quotes:
  160.  
  161. HEX       - separate by commas: d,1A,cd,10,ff,3 
  162. CAPITALS  - between !!: !A!,!hello!          [NEW IN V2.0] 
  163. CONTROL CHARACTERS - preceded by ^: ^M,^m^j,^c,^C,^[,^^
  164. WILDCARDS - ????, ?n (1 <= n <= 9) or ?* (indeterminate)
  165.      The  "|" character is used to display a break in the replace 
  166. string (see below).
  167.  
  168. All ascii letters entered within quotes will be treated as  LOWER 
  169. CASE.  If  you  want  to search upper case letters with  the  "C" 
  170. switch,  or to put upper case letters in the replace string,  you 
  171. must  surround  them  with "!!",  unless you enter  them  as  hex 
  172. characters:  (A = 41, B = 42 ...). Sorry about this, but the CP/M 
  173. command line cannot distinguish upper from lower case.
  174.  
  175. Any  combination  of characters is  valid;  for  clarity,  groups 
  176. should  be separated by commas,  although this is only  necessary 
  177. for individual hex characters: !h!"ello",^m^j,e5,?7,32,!blurk!,^q 
  178. Quotes and !..!  must be closed.  To search/replace the quotation 
  179. mark,  enter it as a hex character ("=22h).   You can search  for 
  180. "!" if you keep it between quotes.
  181.  
  182. The  length  of the find/replace strings is limited to 30  bytes; 
  183. this  length  applies to the strings themselves and  not  to  the 
  184. keyboard entry,  which cannot exceed 127 bytes in all (blame CP/M 
  185. for  this).  Thus  ^j,cd,ff,3d is 4 bytes long.   In the case  of 
  186. indeterminate  wildcards,  up to 255 bytes are allowed,  but  the 
  187. limit of 30 still stands for the find/replace strings themselves.
  188.  
  189. If  you do not enter a replace string,  the  searched-for  string 
  190. will be replaced by nothing, i.e., deleted.
  191.  
  192. WILDCARDS 
  193.  
  194. The wildcard search has a great deal of flexibility.  For obvious 
  195. reasons,  wildcards  cannot appear at the beginning of the search 
  196. string.  (In versions below 2.3 they can't be at the end  either.  
  197. For  some  not-so-obvious reason this seemed a bad thing  at  the 
  198. time.)  The options are as follows:
  199.  
  200. 1. Simple wildcard search: all bytes of the search string will be 
  201. replaced.
  202.  
  203. finrep  zz.txt  /q/ "d"?2"e" "xxyz" will replace all  words  like 
  204. "done", "dare", "dove" etc. by "xxyz"  A maximum of four wildcard 
  205. groups are allowed in this form: thus "a"?"cd"?4"ijk"??"nopq"?"s" 
  206. is a permissible search string
  207.  
  208. 2.  Simple wildcard search with break. Only one wildcard group is 
  209. allowed;  the  replace string is divided in two,  with the  first 
  210. part  replacing  what precedes the wildcards and the second  what 
  211. follows;  the  intermediate bytes are left alone.   The break CAN 
  212. appear at the beginning or end of the replace string to  indicate 
  213. that  the corresponding part of the find string is to be deleted.  
  214. A blank replace string (entered simply as: | ) will delete both.
  215.  
  216. finrep  xx.txt /qw/ "d"?2"e" "xx"|"yzz" will replace the  "d"  in 
  217. this  pattern  with "xx" and the "e" with "yzz";  "done"  becomes 
  218. "xxonyyz", "madame" -> "maxxamyxx", etc.  (This last example only 
  219. works if the "W" switch is used.)
  220.  
  221. 3.  Indeterminate  wildcard  search/replace.   The  indeterminate 
  222. wildcard "?*" must be the only wildcard in the search string.  In 
  223. this  option  the  whole  string from the  beginning  to  end  is 
  224. replaced.   A  maximum of 255 characters will be allowed  in  the 
  225. search string; longer strings will not be found.
  226.  
  227. finrep  blurk.let  /qw/  "xy"?*"zq" "garbage"  will  replace  all 
  228. strings   beginning  and  ending  with  the  indicated   letters: 
  229. "xyrwerwerzq",  "xyuu  is  the nbrzq",  "xy ^C^Yzq" will  all  be 
  230. replaced by "garbage"
  231.  
  232. NB - Since FINREP only looks for one thing at a time, it will not 
  233. find nested pairs of strings,  and will appear to miss some pairs 
  234. where the second half of the search string is over 255 bytes away 
  235. from  the point at which the search began.   (FINREP checks  this 
  236. only every 128 bytes.)  Thus if you are looking for  "the"?*"of", 
  237. FINREP  will  sometimes  miss the apparent "hit" in a  text  like 
  238. this:  ... the [ ... the ... ] of ...
  239. where the [] contain over 255 bytes.   This is not a bug,  but  a 
  240. limitation of the program. 
  241.  
  242. 4.  Indeterminate  wildcard with break.  This is a very  powerful 
  243. option  that allows you,  for example,  to replace  PerfectWriter 
  244. "fences" with WordStar control toggles (& vice versa). Here again 
  245. only  one  wildcard group is allowed in the  search  string;  the 
  246. intermediate bytes are left unchanged.
  247.  
  248. finrep   zap.kkk   /qw/   "123"?*"45"  "6"|"789"   will   replace 
  249. "zz123blurk blurk xxxc oo45rr" by "zz6blurk blurk xxxc oo789rr";
  250. finrep  perf.wri /qwc/ "@"!ux!"{"?*"}" ^s|^s will replace the  PW 
  251. underline fence @UX{ ...  } by WS's ^S ...  ^S  Note that the "C" 
  252. flag is used here to search for caps; if l.c. as well as caps are 
  253. acceptable,  it  could be omitted and the search  string  written 
  254. "@ux{"?*"}".   You  can delete the fences altogether by replacing 
  255. the ^s|^s by | in the last example.
  256.  
  257. One  user thought the word "break" was misleading and  should  be 
  258. replaced  by  "save," since the "|" in the replace  string  means 
  259. that  you  preserve the wildcard part of the  search  string.  In 
  260. other words:  finrep zap.txt /qw/ "<<"?*">>" will kill everything 
  261. between  the "<<..>>" whereas:  finrep zap.txt /qw/ "<<"?*">>"  | 
  262. will just kill the "<<>>" and "save" their contents.  
  263.  
  264. FINREP  can be aborted at any time by typing <ESC> (=1B  HEX).  I 
  265. preferred this to ^C since an extra ^C will be read by CP/M as  a 
  266. Warm Boot.
  267.  
  268. Except when the "V" switch is used, the only screen output is the 
  269. number of strings replaced and, if you use wildcards, the names & 
  270. total  number  of  files  processed.  If  you  want  to  see  the 
  271. replacement procedure in action, use a word-processor!
  272.  
  273. Notes:
  274.  
  275. 1.  FINREP  will modify files of any length;  it uses the  entire 
  276. memory  below the CCP as its buffer,  and writes to disk whenever 
  277. the  buffer  fills up.  Since it doesn't overwrite  the  CCP,  it 
  278. doesn't have to end with a Warm Boot.
  279.  
  280. 2.  There  is no intrinsic limit on the number of  files  allowed 
  281. under the wildcard filename option;  for sanity's sake,  you will 
  282. get an error message if there are more than 255.
  283.  
  284. 3.  If  you want to create a version of FINREP with some  of  the 
  285. switches preset,  run the program without a filename:      finrep 
  286. /[sw1][sw2]../  After  it  returns to the CP/M  prompt,  save  13
  287. finrep1.com  will  keep  the switches  as  you  like  them.  This 
  288. procedure  is  NOT  REVERSIBLE,  so  keep  your  original  FINREP 
  289. unchanged.
  290.  
  291. 4.  In deciding whether to capitalize a whole word/string, FINREP 
  292. looks  at the first two letters.  If the find string has only one 
  293. letter,  only the first letter of the replacement string will  be 
  294. capitalized.   If   the   word  to  be   replaced   has   unusual 
  295. captalization (e.g.  BBrrOOOmm),  use the "C" switch and/or enter 
  296. separate replacement strings for different variants.
  297.  
  298. 5.  In  using  indeterminate wildcards,  you should use  the  "W" 
  299. switch  unless BOTH HALVES of the search string begin and end  on 
  300. word boundaries. 
  301.  
  302. 6.  Re  speed,  FINREP  is  somewhat faster than  Wordstar's  ^QA 
  303. command.  But  if all you want to do is replace a string,  it  is 
  304. over  three  times faster,  since its time includes  loading  and 
  305. saving the file.  Measured on a long (84 K) file,  FINREP took 27 
  306. seconds and WS 34 for a typical search/replace.  But WS needs  at 
  307. least  10 seconds to load and a good minute to save the file  and 
  308. exit.  With a little practice, the command line can be entered as 
  309. fast  as  WS's,  and  it  can  be included  in  SUBMIT  files  or 
  310. reproduced by programs like SYNONYM or my SYN.COM.
  311.  
  312.                               *****
  313.  
  314. FINREP  was  written  at the request of  John-Mark  Stensvaag  of 
  315. Vanderbilt University.   At first I couldn't see the use for  it, 
  316. but  he  convinced me (he is a professor of  Law).  The  wildcard 
  317. features  added  in  v1.1  and  v2.0  were  also  his  idea;  the 
  318. verification  feature  in  v2.2 was ssuggested  by  J.  Olsen  of 
  319. Chicago.  I would appreciate hearing from you about (a) bugs  and 
  320. (b) suggestions for further enhancements.