String Search & Replace?

[Tim Fischer]

Joe,

This was suggested to me, but with the sheer amount of data I need to
convert, it wouldn't be feasible.  I think we figured out that using the
user command, we'd be starting over 22,000,000 child processes in the time
it took to run through the process.  

Using instr & mid as Mark Brumlik suggested seems like the most logical and
efficient approach.

Thanks everyone for the suggestions!!

Tim Fischer

> -----Original Message-----
> From: filepro-list-
> bounces+tim.fischer=trinitytransport.com at lists.celestial.com
> [mailto:filepro-list-
> bounces+tim.fischer=trinitytransport.com at lists.celestial.com] On Behalf Of
> Joe Chasan
> Sent: Thursday, November 04, 2004 2:36 PM
> To: FilePro Mailing List
> Subject: Re: String Search & Replace?
> 
> On Thu, Nov 04, 2004 at 02:16:49PM -0500, Fairlight wrote:
> > This public service announcement was brought to you by J. P. Radley:
> > > | If you are running on a 'nix system you could use unix sed command
> on the
> > > | filePro key file.
> > >
> > > You absolutely could not!
> > >
> > > The sed command operates on text files, with lines terminated by a new
> > > line.  That does not describe a filePro key file.
> >
> > How true.
> >
> > Even if it -did- describe the structure, or there were no newlines and
> > sed will handle the full size of the binary file (I think at least GNU
> > sed will, if not all of them), you'd have other issues, since they're
> > fixed-length fields.  You'd need to subtract off whitespace from any
> > padding at the end of the affected field(s) equivalent to what
> backslashes
> > you added inside each field so that you didn't throw all the offsets.
> >
> > If you didn't, your indexes would automatically be invalidated, and no
> > amount of rebuilding them would help because they'd be increasingly
> > inaccurate in offset as you progressed (assuming it didn't just crash
> after
> > the first expanded record was passed and the next 'x' (20, from memory?)
> > byte header did not appear at the right place, having added more
> characters
> > but taken none away.
> >
> > Indeed, sed would be a Very Bad Tool for this particlar job.  It could
> be
> > done in perl, but you'd want to actually read the map and look at your
> > offsets at all times to make sure you didn't snip space from the end of
> the
> > -next- field if the field you're working with got full, which would lead
> to a
> > field misalignment corruption, etc.  You couldn't just blindly go by the
> > first whitespace gap available after the subtitution--for that matter, a
> > multi-word field with a space in it presents the same issue of space
> being
> > a non-starter for deterministic width adjustment.  (This last point is
> one
> > reason I think fixed-length-fields dependant on whitespace are a Bad
> > Idea--you can't tell "real" spaces from trailer space--they should at
> least
> > be NULL's or something so you can preserve "real" trailer space that's
> > intentional without just running to 999 if that was your field width,
> etc.)
> >
> > And of course, you'd need to decide what to do if a substitution
> actually
> > caused the field to overflow its defined length--chop the tail off, or
> not
> > do the substitution, or something else entirely.
> >
> > It's far more complex than a simple substitution even -if- the OP wanted
> a
> > full-file substitution--which isn't the case, so I suppose it's moot.
> But
> > it -could- be done.  It's just not as trivial as one initially thinks,
> and
> > sed certainly isn't the tool for the job.
> 
> FWIW, if you get the entire file thing out of your heads, and the OP had
> access to sed and was on a *nix box, it certainly can be done with sed,
> just by sending the single string he wanted to send via user processing
> command.
> 
> --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ---
> -Joe Chasan-                      Magnatech Business Systems, Inc.
> joe at magnatechonline.com           Hicksville, NY - USA
> http://www.MagnatechOnline.com    Tel.(516) 931-4444/Fax.(516) 931-1264
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.736 / Virus Database: 490 - Release Date: 8/9/2004
> 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.736 / Virus Database: 490 - Release Date: 8/9/2004