String Search & Replace?

[Fairlight]

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.

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html