Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

@XPREPLACE (4UTILS) issues?

Jun
15
0
First post, so firstly hello everyone!

I've been playing with TCC/LE and 4UTILS, and am having trouble working out why @XREPLACE does what it does.

For example, take this:

Code:
echo '%@XREPLACE["^^(.*?)two",REPLACE,"one two three one two three"]'
As far as I understand it - and I've checked on several online regex testers - the capturing group should be a non-greedy match of zero or more consecutive characters to the next occurance of 'two' , so the above regex should match:

one two

and the resultant output should be:

Code:
'REPLACE three one two three'
But what you actually get is this:
Code:
'REPLACEREPLACE three"'
Am I misunderstanding something?

Note also that there's a trailing double quote, as if it's taken the quotes enclosing the test string to be part of the string. The (very sparse) documentation says that you must enclose a string in quotes if it contains spaces or other problem characters, so I'd expect them to be treated as delimiters and not actual characters to be matched.

I also have some suggestions for the developer, or if the source is available and someone points me to it, I could have a go myself:

1) It would be very useful to have @GMATCH also be able to return the matched contents and positions of capturing groups following an @XMATCH call, using different parameters to signify what is required (number of matches, position of matches, or content of matches).

2) It would be nice to have a @GREPLACE function, that does the same for @XREPLACE

3) A bit extra documentation would be nice, for example stating what regex engine is used. I've been assuming Perl compatible.

The point is to be able to write regex scripts that work on both TCC/LE and the full product, since only the latter has inbuilt regex support.
 
I should have mentioned that removing the non-greedy specifier, ie. change (.*?) to (.*), does then leave it working as expected, apart from the quote issue anyway:

Code:
echo '%@XREPLACE["^^(.*)two",REPLACE,"one two three one two three"]'

gives:

Code:
'REPLACE three"'

as the capturing group is now matching as much as possible, not as little as possible, which is from the start of the string to just before the second 'two'.
 
I think I see what is happening now. In the non-greedy example XREPLACE is finding two matches of the regex '^^(.*?)two' in the string 'one two three one two three' as shown by blue and red.

This surprises me because the second one isn't at the start of the string, so ^ isn't being respected.

Or, alternatively, every time XREPLACE finds a match, and does the corresponding replace, it then starts again at the start of the (now partly changed) string?

Anyone know what it's supposed to do? I hope it's not the second case as that's going to fry my brain - trying to work out regexes which work not just on some user-specified string , but which also don't affect all the partial changes it will go through on the way to XREPLACE's final answer (if there are numerous substitutions).

The real problem here is that I'm trying to use XREPLACE just to find out what capturing groups capture, in a match, because it XMATCH/GMATCH don't make that info available, whereas XREPLACE at least supports references to them in the replacement text. So I'm doing multiple calls to XREPLACE with \1 then \2..etc to get these things, and being bitten by the fact that it's not designed for doing single matches.

So I'd like to repeat my above feature request 1), a bit more loudly! ;-)

And I should also say that 4UTILS/4CONSOLE/SAFECHARS - the only three plugins I've looked at so far - are really excellent - well done to the authors.
 
On Sat, 25 Jun 2011 04:17:02 -0400, you wrote:

|I think I see what is happening now. In the non-greedy example XREPLACE is finding two matches of the regex '*^^(.*?)two*' in the string '*one two** three one two three*' as shown by blue and red.
|
|This surprises me because the second one isn't at the start of the string, so *^* isn't being respected.

The first quote is part of the first match and is removed. Then the second
'(.*)two' is at the beginning of the line. The third parameter does not need to
be quoted (I'll revise the help message); if it is quoted the quoted string is
passed to the Oniguruma RE machine.
 
Does anyone think the following would **NOT** be an enhancement to the way @XREPLACE works?

@XREPLACE[regex,replacement,string] ... quote regex, replacement if they contain whitespace or commas; string need not be quoted; if string is quoted the quotes (outer only) will be removed and replaced after processing; i.e., the Oniguruma RE machine will process the unquoted string and the result will be re-quoted.

Thanks.

On Sat, 25 Jun 2011 04:17:02 -0400, you wrote:

|I think I see what is happening now. In the non-greedy example XREPLACE is finding two matches of the regex '*^^(.*?)two*' in the string '*one two** three one two three*' as shown by blue and red.
|
|This surprises me because the second one isn't at the start of the string, so *^* isn't being respected.

The first quote is part of the first match and is removed. Then the second
'(.*)two' is at the beginning of the line. The third parameter does not need to
be quoted (I'll revise the help message); if it is quoted the quoted string is
passed to the Oniguruma RE machine.
 
Makes sense to me! I'm not yet familar enough with tcc to know what I'm talking about here, but I've seen that you can pass the name (rather than value) of a variable to some things, using %[name] - so it occurred to me that, if it were possible to do this with XREPLACE, that would avoid delimiter vs. actual content issues that you get with passing a string by value.

Would that also be possible/a solution?
 
On Thu, 07 Jul 2011 00:05:53 -0400, you wrote:

|Makes sense to me! I'm not yet familar enough with tcc to know what I'm talking about here, but I've seen that you can pass the name (rather than value) of a variable to some things, using %[name] - so it occurred to me that, if it were possible to do this with XREPLACE, that would avoid delimiter vs. actual content issues that you get with passing a string by value.
|
|Would that also be possible/a solution?

What makes sense to you?

They're all the same. If you

set foo=bar

then these will all produce the same string:

@xreplace[a,e,bar], @xreplace[a,e,%foo], and @xreplace[a,e,%[foo]]
 
From: vefatica
| Does anyone think the following would **NOT** be an enhancement to
| the way @XREPLACE works?
|
| @XREPLACE[regex,replacement,string] ... quote regex, replacement if
| they contain whitespace or commas; string need not be quoted; if
| string is quoted the quotes (outer only) will be removed and replaced
| after processing; i.e., the Oniguruma RE machine will process the
| unquoted string and the result will be re-quoted.

Yes, after thinking about it.
--
Steve
 
On Thu, 07 Jul 2011 09:47:43 -0400, you wrote:

|From: vefatica
|| Does anyone think the following would **NOT** be an enhancement to
|| the way @XREPLACE works?
||
|| @XREPLACE[regex,replacement,string] ... quote regex, replacement if
|| they contain whitespace or commas; string need not be quoted; if
|| string is quoted the quotes (outer only) will be removed and replaced
|| after processing; i.e., the Oniguruma RE machine will process the
|| unquoted string and the result will be re-quoted.
|
|Yes, after thinking about it.

Yes, you think it would **NOT** be an enhancement? Why?
 
From: vefatica

| On Thu, 07 Jul 2011 00:05:53 -0400, you wrote:

Vince: Can you adjust your mail client to use the poster's name, not "you"? As is, one needs to display all post threaded, and go back one, to know whose post you answer. I just noticed this peculiarity. In the past it did not make a difference, but it does in the current thread.

|| Makes sense to me! I'm not yet familar enough with tcc to know what
|| I'm talking about here, but I've seen that you can pass the name
|| (rather than value) of a variable to some things, using %[name] - so
|| it occurred to me that, if it were possible to do this with
|| XREPLACE, that would avoid delimiter vs. actual content issues that
|| you get with passing a string by value.
||
|| Would that also be possible/a solution?
|
| What makes sense to you?
|
| They're all the same. If you
|
| set foo=bar
|
| then these will all produce the same string:
|
| @xreplace[a,e,bar], @xreplace[a,e,%foo], and @xreplace[a,e,%[foo]]

To enhance what Vince wrote, consider that all parameters to a function are expanded by the parser BEFORE they are passed to a command, alias, or function (which last one can be internal, plug-in, or user defined). The parameter expansion may require executing a function. The syntax %[variablename] is a clearer alternative to %variable%, which can become very confusing when the variable are concatenated by entering their names consecutively in the command, or when variablename itself must be expanded.

Vince:
An alternate to enhancing @xreplace might be an XREPLACE command, with 3 or 4 parameters:
from-string
to-string
from-variable-name
to-variable-name
where missing to-variable-name implies same source and target.
The command would be similar in nature to your INC and DEC commands.
--
Steve
 
From: vefatica
| Yes, you think it would **NOT** be an enhancement? Why?

Sorry, you did trigger a double negative... I meant "yes, it would be an enhancement, and AFAIK it would be backward compatible". But see also my other post.
--
Steve
 
On Thu, 07 Jul 2011 10:05:22 -0400, you wrote:

|Vince: Can you adjust your mail client to use the poster's name, not "you"?

I'm using the "Agent" newsreader. I couldn't find where to do that. When I
look at some old email drafts, they do mention the person quoted by name. Does
anyone know where that setting is in "Agent"?
 
What version of Agent are you using? I use Agent and it always does enters the posters name for me. I use 6.00/32.1186. In my version look at Folders, Default Properties. Then Posting Messages, Introductions. they should match what appears with
----- Original Message -----
From: vefatica
To: [email protected]
Sent: Thursday, July 07, 2011 12:31 PM
Subject: RE: [Plugins-t-2949] @XPREPLACE (4UTILS) issues?


On Thu, 07 Jul 2011 10:05:22 -0400, you wrote:

|Vince: Can you adjust your mail client to use the poster's name, not "you"?

I'm using the "Agent" newsreader. I couldn't find where to do that. When I
look at some old email drafts, they do mention the person quoted by name. Does
anyone know where that setting is in "Agent"?
 
What version of Agent are you using? I use Agent and it always does enters the posters name for me. I use 6.00/32.1186. In my version look at Folders, Default Properties. Then Posting Messages, Introductions. they should match what appears with img69.imageshack.us/img69/2463/agentr.jpg "
----- Original Message -----
From: vefatica
To: [email protected]
Sent: Thursday, July 07, 2011 12:31 PM
Subject: RE: [Plugins-t-2949] @XPREPLACE (4UTILS) issues?


On Thu, 07 Jul 2011 10:05:22 -0400, you wrote:

|Vince: Can you adjust your mail client to use the poster's name, not "you"?

I'm using the "Agent" newsreader. I couldn't find where to do that. When I
look at some old email drafts, they do mention the person quoted by name. Does
anyone know where that setting is in "Agent"?
 
To make it simplier here is the contents, field by field.

F/u usenet: On %date%, %from% wrote:\n

email reply to usenet: On %date%, in %newsgroups% you wrote:\n

FWD usenet: On %date%, in %newsgroups% %from% wrote:\n

reply to email: On %date%, you wrote:\n

FWD email: On %date%, %from% wrote:\n

All fields for subject of FWD emails: (fwd) %subject%
----- Original Message -----
From: vefatica
To: [email protected]
Sent: Thursday, July 07, 2011 12:31 PM
Subject: RE: [Plugins-t-2949] @XPREPLACE (4UTILS) issues?


On Thu, 07 Jul 2011 10:05:22 -0400, you wrote:

|Vince: Can you adjust your mail client to use the poster's name, not "you"?

I'm using the "Agent" newsreader. I couldn't find where to do that. When I
look at some old email drafts, they do mention the person quoted by name. Does
anyone know where that setting is in "Agent"?
 
On Fri, 08 Jul 2011 02:12:51 -0400, Charles G <> wrote:

|reply to email: On %date%, you wrote:\n

That's what I have and what Steve asked that I change (and what your replies
contain). I changed "you" to "%From%". I'll see how it works right now.
 
On Thu, 07 Jul 2011 00:05:53 -0400, you wrote:

|Makes sense to me! I'm not yet familar enough with tcc to know what I'm talking about here, but I've seen that you can pass the name (rather than value) of a variable to some things, using %[name] - so it occurred to me that, if it were possible to do this with XREPLACE, that would avoid delimiter vs. actual content issues that you get with passing a string by value.
|
|Would that also be possible/a solution?

What makes sense to you?

They're all the same. If you

set foo=bar

then these will all produce the same string:

@xreplace[a,e,bar], @xreplace[a,e,%foo], and @xreplace[a,e,%[foo]]

I don't think I explained myself very well. I meant that I could pass XPREPLACE the *name* of a variable, not its value, thereby avoiding any expansions in its value by tcc. The above both pass foo by value.

Say for example (I'm just inventing a syntax for the purpose of illustration here)

@xreplace[a,e,@foo]

XREPLACE sees the parameter '@foo' and recognises the @ prefix as an instruction to use the variable named 'foo' (not the actual value 'foo') thereby getting the value 'bar'.

As a newbie, the thing I'm having difficulty with in tcc generally is continuously fighting unintended expansion issues when passing strings around in scripts (eg. to variable functions). I've had cases where I needed to use setdos /x to turn off some expansions, except that I couldn't because I needed it to be switched on for the actual task at hand.

I guess you're going to get that when you make a programming language out of command line syntax/semantics.

I've frequently found myself wondering why there isn't a standard "pass by reference" syntax in tcc, as suggested above for XREPLACE, to help avoid unintended expansions and/or control when they happen. Sometimes you just want a string from the user (or text file) not to be fiddled with excpet where you explicitly fiddle with it.

But as I said, I'm a newbie and am probably misunderstanding or overlooking something.
 
On Sat, 09 Jul 2011 08:05:08 -0400, kwa <> wrote:

|They're all the same. If you
|
|set foo=bar
|
|then these will all produce the same string:
|
|@xreplace[a,e,bar], @xreplace[a,e,%foo], and @xreplace[a,e,%[foo]]
|---End Quote---
|I don't think I explained myself very well. I meant that I could pass XPREPLACE the *name* of a variable, not its value, thereby avoiding any expansions in its value by tcc. The above both pass foo by value.
|
|Say for example (I'm just inventing a syntax for the purpose of illustration here)
|
|@xreplace[a,e,@foo]

I still don't get it. If you want @XREPLACE (or any function) to **act** on the
name of a variable, pass the name of the variable (@XREPLACE[a,e,foo]); if you
want it to act on the value, pass the value (@XREPLACE[a,e,%foo]). If the
variable name is itself a variable (%varname) then pass the variable name like
this: @XREPLACE[a,e,%varname]; and pass the value like this:
@XREPLACE[a,e,%[%varname]]. In this respect, @XREPLACE is the same as all other
variable functions in TCC.
 
I don't think I explained myself very well. I meant that I could pass XPREPLACE the *name* of a variable, not its value, thereby avoiding any expansions in its value by tcc. The above both pass foo by value.

It's easy enough to do, but you're still going to have difficulty (a) setting the variable in the first place, and (b) reading the value later.
 
It's easy enough to do, but you're still going to have difficulty (a) setting the variable in the first place, and (b) reading the value later.

Yes that's true, but at least it eliminates the majority of unwanted expansions, in my (admittedly limited) experience anyway.

In what I've been playing with, I'm getting input from the user, or a text file, then manipulating it in various ways (including regex testing and passing through various other functions), then using it at the end. I can't guarantee that the input doesn't contain characters meaningful to tcc's expansion rules. If I could avoid that by not having to repeatedly use it by value, it would be a big help.

When I need to initialise the variable at the start, and use it at the end, I can use setdos /x with much less risk of side effects.

Of course you still have the problem that functions which act on strings return their results as a return value, so you use them in a 'set' command, and expansion happens there too (iirc).

Perhaps a nicer, and more global, way would to have a different way of referring to a variable for the case when you don't want expansion to occur.

for example:
%foo - the contents of 'foo', expanded
$foo - the contents of 'foo', not expanded

echo %@XREPLACE[a,e,%bar] - %bar gets expanded, as does the XREPLACE return value

echo $@XREPLACE[a,e,$bar] - neither %bar nor the XREPLACE return value get expanded

I'm just ruminating here, I haven't really thought this through.
 
I still don't get it. If you want @XREPLACE (or any function) to **act** on the
name of a variable, pass the name of the variable (@XREPLACE[a,e,foo]); if you
want it to act on the value, pass the value (@XREPLACE[a,e,%foo]). If the
variable name is itself a variable (%varname) then pass the variable name like
this: @XREPLACE[a,e,%varname]; and pass the value like this:
@XREPLACE[a,e,%[%varname]]
. In this respect, @XREPLACE is the same as all other
variable functions in TCC.

Yes I know that. But the point is that, in doing so, the resultant value will be subject to expansion before it is passed (which you might not want), and may also contain characters that break the syntax of the command line/function. This can easily be the case if the text came from user input or a text file, and might contain anything.

If you can instead tell the function "use the value of the variable with this name" you bypass those possibilities, because that value never appears in the command.

It's just the tcc equivalent of pass by reference, that most every other programming/scripting language has!
 
So can someone give me the definitive answer of why:

echo '%@XREPLACE["^^(.*?)two",REPLACE,"one two three one two three"]'

produces:

'REPLACEREPLACE three"'

?

(the reason that text substitution was done, not the quotes)

When doing this on a java regex tester (eg.this) you have to delete the start of line specifier (^^) to get that result, which is what I'd have expected.
 
Does anyone think the following would **NOT** be an enhancement to the way @XREPLACE works?

@XREPLACE[regex,replacement,string] ... quote regex, replacement if they contain whitespace or commas; string need not be quoted; if string is quoted the quotes (outer only) will be removed and replaced after processing; i.e., the Oniguruma RE machine will process the unquoted string and the result will be re-quoted.

Thanks.

On reflection, that wouldn't be backwards compatible, would it?

How would XREPLACE know if a prefixed quote was part of the actual text to be passed to Oniguruma (as I understand is the case now, therefore required for backward compatibility), or a delimeter to be stripped (new)?

To eliminate ambiguity, wouldn't it have to require that the delimiting quotes were *always* supplied? Which means not backwards compatible.

Or am I missing something?

If I'm not, then one solution could be a new function XREPLACEQ which requires quoted parameters, and which strips and discards them before calling XREPLACE internally. For me, it doesn't really matter if it doesn't re-apply them to the string it returns - they weren't part of the actual 'real' input to start with, so it's probably better if they aren't part of the output and have to be manually stripped.

And, just to be clear, this doesn't eliminate the need (imho) to have some way of passing strings by reference to XREPLACE(Q), to guarantee that, nomatter what the text is, it gets to XREPLACE(Q) unchanged and without risk of breaking the command line. This does, however, eliminate the need for the above quote stripping feature.

Unless SAFECHARS could be helpful for that? I've so far assumed not, as shifting character codes around doesn't sound too transparent to a regex engine.
 
How would XREPLACE know if a prefixed quote was part of the actual text to be passed to Oniguruma (as I understand is the case now, therefore required for backward compatibility), or a delimeter to be stripped (new)?

It wouldn't know. I'll leave the quotes as they are.

What about the [non]greediness question? I originally wrote @XREPLACE to function like SED's s/xxx/yyy/g, ... the "g" indicating "global" (replace all non-overlapping occurrences). The fact that "g" is a SED option (and not a regex spec) suggests that you can't make that distinction with regexes alone. I could change @XREPLACE to replace only the first occurrence and add @XREPLACEG to work as @XREPLACE does now.

What about @XREPLACE's processing TCC escape sequences (in all three parameters)? It does that now. I could remove it.

And, just to be clear, this doesn't eliminate the need (imho) to have some way of passing strings by reference to XREPLACE(Q), to guarantee that, nomatter what the text is, it gets to XREPLACE(Q) unchanged and without risk of breaking the command line.

You'll have to talk to Rex about that. No variable function (of hundreds of built-in and plugin ones) has any control over what parameters are passed to it. SETDOS /x-4 works pretty well.
 
On Sun, 10 Jul 2011 11:25:06 -0400, vefatica <> wrote:

|What about the [non]greediness question? I originally wrote @XREPLACE to function like SED's s/xxx/yyy/g, ... the "g" indicating "global" (replace all non-overlapping occurrences). The fact that "g" is a SED option (and not a regex spec) suggests that you can't make that distinction with regexes alone. I could change @XREPLACE to replace only the first occurrence and add @XREPLACEG to work as @XREPLACE does now.

Or I could add a parameter ... @XREPLACE[regex,replacement,N,string] where ...

N = 0 or empty - replace all occurrences

N > 0 - replace up to N occurrences
 
On Sun, 10 Jul 2011 12:42:04 -0400, vefatica <> wrote:

|On Sun, 10 Jul 2011 11:25:06 -0400, vefatica <> wrote:
|
||What about the [non]greediness question? I originally wrote @XREPLACE to function like SED's s/xxx/yyy/g, ... the "g" indicating "global" (replace all non-overlapping occurrences). The fact that "g" is a SED option (and not a regex spec) suggests that you can't make that distinction with regexes alone. I could change @XREPLACE to replace only the first occurrence and add @XREPLACEG to work as @XREPLACE does now.
|
|Or I could add a parameter ... @XREPLACE[regex,replacement,N,string] where ...
|
|N = 0 or empty - replace all occurrences
|
|N > 0 - replace up to N occurrences

Better (?) ...

@XREPLACE[regex,replacement,[N,],string]

[N,] - replace up to N occurrences (N = 0 = all)
 
It wouldn't know. I'll leave the quotes as they are.

What about the [non]greediness question? I originally wrote @XREPLACE to function like SED's s/xxx/yyy/g, ... the "g" indicating "global" (replace all non-overlapping occurrences). The fact that "g" is a SED option (and not a regex spec) suggests that you can't make that distinction with regexes alone. I could change @XREPLACE to replace only the first occurrence and add @XREPLACEG to work as @XREPLACE does now.

I've never used SED. so I cant draw any parallels with that.

We have to be careful with terminology here - greediness/non-greediness works fine in regexes using the ? qualifier, notwithstanding that there's apparently a problem with the above example I gave that uses it (which is probably caused by something else). It doesn't directly control how many replacements are done, just the mount of text that a single regex fragment will be allowed to match.

As regards the different issue of how many replacements XREPLACE would do (the suggested new 'N' parameter), it certain seems a useful feature to have.

As I mentioned in an earlier post, in the example I gave I can't understand why XREPLACE returns what it does. It seems to be either

1) Ignoring the start of line fragment (^) in second and subsequent searches

2) Doing second and subsequent searches at the start of the (modified) string, so ^ always matches, instead of at the character following where the last substitution was just done. That could be a straightforward bug.

Can you shed any light on which of these it is, or if it's something else?

vefatica said:
What about @XREPLACE's processing TCC escape sequences (in all three parameters)? It does that now. I could remove it.

I need to think about that some more. On obvious initial concern is breaking backwards compatibility.

It raises a question though. If tcc is processing escape sequences and so is XREPLACE internally, if I want to use ^ in a regex string (start of line) do I need to use ^^, ^^^ or ^^^^ in my XREPLACE call?

vefatica said:
You'll have to talk to Rex about that. No variable function (of hundreds of built-in and plugin ones) has any control over what parameters are passed to it. SETDOS /x-4 works pretty well.

Yes I'm aware of that. The question is really "would tcc's batch language be a better language if it had pass-by-reference parameters?". For me its a big yes, for the reasons given. It could be considered for a future version.

Without knowing how tcc works internally its hard to say, but I'd have thought this was something that wouldn't require changing every function, including those in plugins, because it's about how tcc assembles parameters before dispatching to the function being called, and what it does with the return value. From the function's internal point of view, it would still receive its parameters by value, as before.

I find setdos /x to be a clunky solution and, as pointed out earlier, I've hit cases where I couldn't use it because I needed expansion to be on for one string and off for another, in the same expression.

For the here and now, as far as XREPLACE is concerned, I was suggesting that XREPLACE could define its own pass-by-reference scheme, to nicely sidestep around expansion and quoting issues, where they might be a problem.

For example, a parameter of the form @FRED could be defined to mean "dont use @FRED as the actual parameter, use the value held in the variable named FRED instead".

But to avoid possible backwards compatibility issues, that would have to be implemented in a new function, which just checks for this type of parameter, performs any required substitutions, and calls the existing XREPLACE.
 
On Mon, 11 Jul 2011 00:12:42 -0400, kwa <> wrote:

|2) Doing second and subsequent searches at the start of the (modified) string, so ^ always matches, instead of at the character following where the last substitution was just done.

It used to update the beginning of the string along with the beginning of the
search area ... thus always thinking it was at the beginning of a line. I fixed
that.

I also added the "up-to-N replacements" and removed messing with quotes in the
third parameter.

|---Quote (Originally by vefatica)---
|What about @XREPLACE's processing TCC escape sequences (in all three parameters)? It does that now. I could remove it.
|---End Quote---
|I need to think about that some more. On obvious initial concern is breaking backwards compatibility.
|
|It raises a question though. If tcc is processing escape sequences and so is XREPLACE internally, if I want to use ^ in a regex string (start of line) do I need to use ^^, ^^^ or ^^^^ in my XREPLACE call?

TCC doesn't escape parameters to plugin functions. You have to use "^^" because
@XREPLACE escapes all three of it's strings. That could be useful because TCC's
parser will choke on unmatched double-quotes or back-quotes (maybe other
things). I could escape all, none, or any combination of the three arguments.

There's a new 4UTILS at ftp://lucky.syr.edu/4plugins/4utils.zip

It still escapes all three args, but I'd consider changing that. Below is the
new help message.

@XREPLACE[pattern,replacement[,N],string]

replace [up to N] occurrences of pattern in string

<pattern> may be regex
<replacement> may reference captures \0 ... \31 or \{0} ... \{31}
\n = newline, \t = tab; \\ = backslash
"quote" pattern/replacement containing whitespace or commas

TCC escape sequences are processed in all three parameters
 
Wow..fast work Vince - I'll download it and check it out now.

I was thinking some more about the escape processing. I'd prefer not to have it, as the strings being processed are nothing to do with tcc (they come from a third party supplied text file). But I could understand if others saw it differently.

What about providing a second function, or new parameters, to allow no escaping?
 
I can confirm that the test case I posted now works as expected:

Code:
echo '%@XREPLACE["^^(.*?)two",REPLACE,"one two three one two three"]'
^(.*?)two REPLACE "one two three one two three"
'REPLACE three one two three"'

What is the middle line? Is XREPLACE echoing its parameters to stdout?
 
Back
Top