TP> What I need to do is to create a filter (REXX would be nice),
TP> where it would search the folders for a key phrase/word then
TP> ask if I wish to 'read' those files found with matching
TP> word/string, and/or ask me if I wish to :
TP> 1. copy to ascii file
TP> 2. strip out the word/phrase or the whole line
TP> 3. strip out 'n' lines above and 'n' lines below the found
TP>      word/phrase.
TP> 4. Ask if I wish to read 'n' lines above and 'n' lives below
TP>      the found word/string in the message(s) ?

     Hmm...  that sounds very similar to a situation I was up against
where I was performing IBM Remote Job Entry (RJE) via Job Control
Language (JCL) Quality Assurance (QA) validation testing of the
Tasmanian Validation Suite of a Pascal 6000 class compiler.  There were
JCL control "cards" (i.e. slash commands) above the retrieved data, as
well as batch spooler "Start-Of-Job" and "End-Of-Job",
"tear pages" on
each job returned.  What I did was whip up one of those long pipelines
that UNIX is so rightly famous for.  I believe that I had a GREP that
piped off to MORE that would call a YES/NO TEE that would conditionally
drop into SED/ED with a called script and strip the junk out of the
output.  I am not sure if you could get away with that under DOS with
4DOS, as it takes quite an elaborate jobstream.


TP> In addition to searching/looking at file/message contents, I
TP> need to 'strip out' several lines of advertising that are
TP> appended to each/every email coming via a forum.  (They place
TP> adverts at the bottom of every email that comes through within
TP> the forum).  So far I've had a look at *nix tools 'head' and
TP> 'tail' in conjuntion with 'grep' ...... but REXX or 4os2 'btm'
TP> would be a better solution as it requires only one call, whereas
TP> tail/grep etc. would involve 3 calls ....


     Well, the question here is -- Do you want this editing to take
place automatically ? ...or... Do you want a human to be "eyeballing"
the data as it is processed ?

     If you want the data to be processed automatically, I would say:

"THIS LOOKS LIKE A JOB FOR SUPERMAN !"

  ...er, I mean...

"THIS LOOKS LIKE A JOB FOR SED -- THE STREAM EDITOR !"

  On the other hand, if you wish for a human being to take a hand in the
data processing, you will need an editor that supports having customized
macros that can be bound to programmable function (PF/FN) keys.  The
editor should be extensible, so that you can write your own custom
editing routines.  The editor should have macros that could be bound to
command keys.  The xtensible ro should have an almost
LISP-like flexibility.  If only I  of such an editor!  (Pardon me
while I unpack some raincoats....  Hey!  These aren't yellow slickers!
Made in Scotland?  E-E-E-E!  MACS!)  I don't mean to stall, man, but
such an editor should come  style and  flair.  (Pardon me
while I mail off some fast food....  First, I'll mail off these e-fries.
Then, I'll mail off some e-macs.)  Oh, if only someone  of such an
editor!  (Pssst!  You might try MIT GNU EMACS, also, by modifying its
news reader functions to perform a bit of editing as it goes along.)

     REXX is good, too.  It all comes down to how much variation there
is in your data set.  I would recommend SED as a "data grinder" as you
can use expressions in its command file.  If the data is something
simple (e.g. toss out the last ten lines) EDLIN or DEBUG will work as
well.  If there is a tremendous amount of variation in the output data
set, you can throw EMacs e-lisp parser or REXX at it.  GNU/UNIX SED, The
Stream Editor, is desgined for this kind of stuff, though....

--- PCBoard (R) v15.4/M 10 Beta