String Search & Replace?

[Joe Chasan]

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