Here's an example of why imho something has to be done regarding quotes.
The testcase I've been using is this:
That's (imho) an entirely natural way to use XREPLACE. I quoted the third string because it contains spaces. I might also have done that if it contained commas, or if I didn't know what syntax-breaking characters it might contain.
I thought I'd redirect the output to a file:
and got this output:
Ignore the first line - I asked about that in a previous post. The second line showed the redirection clause being ignored and echoed in the output. At first I didn't understand why - I thought it might have been something to do with the reason why the first line appeared.
But then I realised it's because the first quote in "one two three one two three" is treated as input, matched by the (.*), and replaced by REPLACE, so the echo statement resolves to:
echo REPLACE three" >log.txt
Which seems to make tcc treat the redirection clause as normal text to be echoed, despite the fact that there's no closing " so it's really not meaningful syntax.
I'd argue that isn't intuitive behaviour. While it certainly isn't consistently applied throughout tcc's variable functions, there are other places in tcc where double quotes are taken as delimiters not part of the actual text, for example
returns 3, not an error (because " isn't meaningful in a numeric expression), because the quotes are interpreted as delimiters and not part of the actual data.
I believe XREPLACE should do the same or, if backward compatibility is important, there should be an XREPLACEQ which treats enclosing quotes as delimiters, and makes them mandatory.
A further observation is that quotes on the regex parameter are seemingly treated as delimiters, and discarded, if they are present.
So the following are functionally identical:
So I'd also argue that XREPLACE isn't even consistent with itself as regards how it handles quoted parameters - if they're on the regex they're ignored, if they're on the target string they're literal.
I hope I don't sound like I'm whinging or unappreciative - I'm not. I think 4utils is great and it's great that tcc has a community doing this type of stuff for the benefit of others.
Nor do I claim to be right - as a newbie, it's quite likely I'm wrong in my understanding and/or expectations.
The testcase I've been using is this:
Code:
echo %@XREPLACE["^^(.*)two",REPLACE,"one two three one two three"]
I thought I'd redirect the output to a file:
Code:
echo %@XREPLACE["^^(.*)two",REPLACE,"one two three one two three"] >log.txt
Code:
^(.*)two REPLACE "one two three one two three"
REPLACE three" >log.txt
Ignore the first line - I asked about that in a previous post. The second line showed the redirection clause being ignored and echoed in the output. At first I didn't understand why - I thought it might have been something to do with the reason why the first line appeared.
But then I realised it's because the first quote in "one two three one two three" is treated as input, matched by the (.*), and replaced by REPLACE, so the echo statement resolves to:
echo REPLACE three" >log.txt
Which seems to make tcc treat the redirection clause as normal text to be echoed, despite the fact that there's no closing " so it's really not meaningful syntax.
I'd argue that isn't intuitive behaviour. While it certainly isn't consistently applied throughout tcc's variable functions, there are other places in tcc where double quotes are taken as delimiters not part of the actual text, for example
Code:
echo %@EVAL["1+2"]
returns 3, not an error (because " isn't meaningful in a numeric expression), because the quotes are interpreted as delimiters and not part of the actual data.
I believe XREPLACE should do the same or, if backward compatibility is important, there should be an XREPLACEQ which treats enclosing quotes as delimiters, and makes them mandatory.
A further observation is that quotes on the regex parameter are seemingly treated as delimiters, and discarded, if they are present.
So the following are functionally identical:
Code:
echo %@XREPLACE["^^(.*)two",REPLACE,"one two three one two three"]
echo %@XREPLACE[^^(.*)two,REPLACE,"one two three one two three"]
So I'd also argue that XREPLACE isn't even consistent with itself as regards how it handles quoted parameters - if they're on the regex they're ignored, if they're on the target string they're literal.
I hope I don't sound like I'm whinging or unappreciative - I'm not. I think 4utils is great and it's great that tcc has a community doing this type of stuff for the benefit of others.
Nor do I claim to be right - as a newbie, it's quite likely I'm wrong in my understanding and/or expectations.