ADV: filePro Global Search and Replace is here!

[Fairlight]

On Tue, Sep 25, 2012 at 06:17:40PM -0400, J. P. Radley thus spoke:
> Mark Luljak propounded (on Tue, Sep 25, 2012 at 05:47:42PM -0400):
> | The Fairlight fpgsr utility is a global search-and-replace tool meant to
> | work specifically with filePro processing tables.  
> 
> I assume you're beyond using a simple sed command.  :-)

It does a lot of sanity checking and safety precautions sed wouldn't
handle, yeah.  Same concept, just a lot more robust.

> What happens if the original string is a substring of something in the
> processing table?
> 
> Suppose I have lines that read:
> 
> 	lookup george  k=2 i=a -nx
> 	lookup georgetown k=4 i-c -nx
> 
> and I ask to change "george" to "york".
> 
> Will "georgetown" morph to "yorktown"?  Or must the original string be
> surrounded by a pair of spaces or a pair of quotes or parentheses?

Yes, actually it would morph in that case.

It -is- possible for me to add (*counts*) about five lines of code to
conditionally re-enable perl extended regex matching.  In that case, you
could use delimiters like \Wgeorge\W and it would never morph georgetown.

However, if I do that, then users are on their own in terms of handling
regex syntax properly.  For instance, if you wanted to replace something
like:

::Msg="<a href=\"http://foo.com/bar.html\">":

...and change anything that included the quoted doublequotes, you'd need to
make sure that you properly got \\" into perl.  This may be further
complicated by whatever shell you're using to run the command itself having
its own ideas on what to do with backslashes, etc.

That's one reason I actually made it literal, rather than regex-based.
I was worried people would try to use it on something like that and not
realise exactly what they were getting before it fired off.  Like I said,
I could add about five lines (two of which are closing curly braces) and
conditionally restore regex ability to the code.  I had to go out of my way
to remove it, as you can imagine.

You make a valid point.  I'll likely add the option this evening and roll
v1.1.  The most complicated part is recompiling the Windows version, and
that's semi-automated.

Actually, I just thought of a safeguard.  If people know enough to use
extended regex, they'll know what the resultant internal patterns equate
to.  I can just add a tiny little extra yes/no display & confirm loop to
show them what's about to happen, and enable that loop if regex is turned
on.  That way they can bail out if they don't like the way it got into the
interpreter after the shell had its way with the input.  I think that's a
fairly wise way to handle it so nobody gets unexpectedy blindsided.  And it
conditionally reinstates the original intended power before I added a bunch
of code to tone down the power.  Cos I'd personally use and prefer it with
extended regex.

Thanks for the feedback, JP!

mark->
-- 
Audio panton, cogito singularis.