Hi Barry,
(Wednesday May 13 1998 11:33) Barry Block to Ted Menks about: parsing
 TM>> What is GREP? What is it part of, and where does one find it?
 BB>      File request fgrep*.* and xgrep*.*
Where? Your uplink? And what *is* grep? That question still stands...
 TM>> *processing* the data A line may contain more than one parameter,
 TM>> and some of the parameters may consist of several "words".
 TM>> Assigning these parameters to a number of variables correctly is
 TM>> the issue
 BB> Do you have my fbbs.btm?
If I ever had it, it must have gotten misplaced somehow... ;-)
 BB> It shows a way to process params in any order. It checks at least 9
 BB> of them.
That's great (to say the least), but does that refer to command-line 
parameters only, or does it also include a line of parameters read in from a 
text-file? The latter would after all be the problem I'm trying to discuss 
here. How do I cut the read line correctly into separate parameters? The best 
suggestion yet was to use fixed-length parameters, so that @instr[] and 
@substr[] functions might be used to parse it. I'm not very pleased with the 
idea, but if need be...
Recursively calling the batch with the data-line as a "parameter-set" clearly 
solves the problem of cutting it into separate parameters, and how they're 
processed is of course dependant on what the batch is supposed to do.
However, such recursively calls (which I prefer for my personal use) may 
confuse others who are trying to adapt my products to their own specific 
needs, causing trouble all over.
CUL8R,
  Ted Menks  2:2449/236.51 / 2:284/412.51  PGPkey: 2048/1B2ACCED (by RRQ)
... If at first you don't succeed, have somebody else do it for you!
--- 4Dos v6.01a ---
(2:2449/236.51)
---------------