JREPL.BAT v8.6 - regex text processor with support for text highlighting and alternate character sets

[foxidrive]

Thanks, I do feel that JREPL is a bit of a Swiss Army Knife.

The Swiss are renown for good quality stuff. And ABBA. I like ABBA tbh.

Dave, can I suggest that /N .... have an option for that character?

EG: /N 3 "|"

Good idea, except I cannot add the delimiter as a second argument to the /N switch because it would break existing scripts.

Thanks Dave, that's very useful.

I'll just comment here if it is not too late that parsing the /N switch in a different way could obviate the need for a /D switch and not break existing scripts.

/N "3|"
/N "3:"
/N "3+"
/N 3

If you could make all these legal syntax then the delimiter character can be included, making it more intuitive for the user and simpler documentation.

That's all up to you and your plans for jrepl of course.



I just looked at the new documentation for /D and see it has other uses too.

/D Delimiter

Specifies the Delimiter string to use after line numbers and/or
byte offsets that are output due to the /N or /OFF options.
The default value is a colon.

RTFM should be tattooed on everyone's forehead at birth so they see it in the mirror every day and don't forget.
I forget it a fair bit myself. LOL

Mind you some manuals are so difficult to follow that they should come with complimentary headache pills...

[Squashman]

And ABBA. I like ABBA tbh.

Who doesn't like ᗅᗺᗷᗅ!

[Sponge Belly]

Hi Foxi!

Sweden gave the world ABBA, Volvo, and Stieg Larsson.

We have Switzerland to thank for yodeling, cuckoo clocks, and Roger Federer.

Need I say more?

- SB

[Squashman]

Hi Foxi!

Sweden gave the world ABBA, Volvo, and Stieg Larsson.

And Jenny Rissveds!!!!!!

We have Switzerland to thank for yodeling, cuckoo clocks, and Roger Federer.

Need I say more?

- SB

And Nino Schurter!!!!!!

[foxidrive]

Stieg Larsson. And Jenny Rissveds!!!!!! Roger Federer. And Nino Schurter!!!!!!

Code: Select all

call jrepl "books|bikes|tennis" "ABBA" /i /f Switzerland.txt

Hmmm Books, bikes, tennis, more bikes.... I'd rather have Abba if it's all the same to you blokes.

[Mike D]

JREPL V4.5 can return errorlevel=1 when the new text is the same as the original text. This is a problem for me because I want to update the (internal) revision date in various files, and I don't want it to register as a failure just because I've previously updated the file on the same day.

Here's some code that illustrates the problem.

Code: Select all

@echo off & setlocal & echo.
echo abc > in.txt
call jrepl "a.c" "abc" /f in.txt
echo    1: %errorlevel%
call jrepl "a.c" "axc" /f in.txt /o tmp.txt
set e=%errorlevel%
type tmp.txt
echo    2: %e%
call jrepl "a.c" "abc" /f tmp.txt
echo    3: %errorlevel%
echo abc | jrepl "a.c" "abc"
echo    4: %errorlevel%

The output is:

Code: Select all

abc 
   1: 1
axc 
   2: 0
abc 
   3: 0
abc 
   4: 0

Item 1 shows the problem.

Items 2 and 3 are a workaround, by changing the text to a dummy value, then changing it back to the required one.

Item 4 shows that the problem doesn't occur if the input is piped to JREPL, instead of being read from a file.

[thefeduke]

JREPL V4.5 can return errorlevel=1 when the new text is the same as the original text. This is a problem for me because I want to update the (internal) revision date in various files, and I don't want it to register as a failure just because I've previously updated the file on the same day.
... ... ... ...
Item 4 shows that the problem doesn't occur if the input is piped to JREPL, instead of being read from a file.

I suggest that you redefine failure in light of:

::: Return Codes:
:::
::: 0 = At least one change was made and /JMATCH not used
::: or at least one match returned and /JMATCH was used
::: or /? was used
:::
::: 1 = No change was made and /JMATCH not used
::: or no match returned and /JMATCH was used

In your case, JMATCH was not used and the Return codes are consistent.

Your test 4 returned

Code: Select all

abc
   4: 1

in my environment.

John A.

[dbenham]

JREPL V4.5 can return errorlevel=1 when the new text is the same as the original text. This is a problem for me because I want to update the (internal) revision date in various files, and I don't want it to register as a failure just because I've previously updated the file on the same day.

That behavior is by design (and documented).

Code: Select all

C:\test>jrepl /?return

  Return Codes:

      0 = At least one change was made and /JMATCH not used
          or at least one match returned and /JMATCH was used
          or /? was used

      1 = No change was made and /JMATCH not used
          or no match returned and /JMATCH was used

      2 = Invalid call syntax or incompatible options

      3 = JScript runtime error

In your case you want to treat ERRORLEVEL of 0 and 1 as Success, and 2 and 3 as Error.
You can clear the 1 "error", but still preserve 2 and 3, with something like

Code: Select all

call jrepl "search" "replace" /f source.txt & if not errorlevel 2 (call )

[thefeduke]

In your case you want to treat ERRORLEVEL of 0 and 1 as Success, and 2 and 3 as Error.
You can clear the 1 "error", but still preserve 2 and 3, with something like

Code: Select all

call jrepl "search" "replace" /f source.txt & if not errorlevel 2 (call )

Because you have different codes with /JMATCH I adapted this error handling to clear the "1 code" for Mike:

Code: Select all

@echo off & setlocal enableDelayedExpansion & echo.
echo.%~1 | jrepl "a.c" "abc"
IF errorlevel 2 Exit /b 2
IF "%errorlevel%" EQU "0" (echo.Changed to abc.) Else (
    echo.%~1 | jrepl "a.c" $0 /jmatch
    IF "!errorlevel!" EQU "0" (echo.Previously changed.) Else Echo search 'a.c' format not found. 
) 
Exit /b

John A.

[Mike D]

Thanks for the replies.

Your test 4 returned [errorlevel=]1 in my environment.

It definitely returns 0 on the computer I was using, which is running 32-bit Windows XP. I checked on a computer running 64-bit Windows 10, and on that it returns 1.

That behavior is by design (and documented).

Strangely enough, I did read the documentation while I was investigating the problem . My difficulty was with the meaning of 'change'. For example, most, if not all, text editors consider that a file has been changed when you substitute some text for identical text (and they therefore prompt you to save the file before exiting).

It seems to me that knowing whether the search term has been found is more important than knowing whether an identical (or effectively identical, in the case of regular expressions) term has been substituted. But that may be a bias because of the particular application I have in mind: if a file doesn't have a revision date, it's an error, but if the old revision date is the same as the new, I don't care.

Based on the suggested ways of handling the problem, I came up with the following code, which is better than my original workaround because the file is processed twice only if the replacement text is the same as the original text (which usually wouldn't be the case).

Code: Select all

@echo off & setlocal & echo.
call :test axc
call :test abc
call :test abx
exit /b

:test
echo %1 > in.txt
call jrepl "a.c" "abc" /f in.txt /o out.txt && (echo %1 - 'a.c' changed to abc & exit /b 0)
call jrepl "a.c" "###" /f in.txt > nul && (echo %1 - 'a.c' not changed & exit /b 0)
echo %1 - 'a.c' not found
exit /b 1

I haven't treated return codes 2 & 3 separately, as I think they're unlikely to occur (famous last words?).

Without the superfluous diagnostic messages, the subroutine simplifies to

Code: Select all

:test
echo %1 > in.txt
call jrepl "a.c" "abc" /f in.txt /o out.txt && exit /b 0
call jrepl "a.c" "###" /f in.txt > nul && exit /b 0
echo 'a.c' not found (input file contains '%1').
exit /b 1

Thanks again for your help.

[thefeduke]

It definitely returns 0 on the computer I was using, which is running 32-bit Windows XP. I checked on a computer running 64-bit Windows 10, and on that it returns 1.

As an aside, because it does not figure in your solution, the latter does match my Win7-based Windows 10.

Based on the suggested ways of handling the problem, I came up with the following code, which is better than my original workaround because the file is processed twice only if the replacement text is the same as the original text (which usually wouldn't be the case).

I haven't treated return codes 2 & 3 separately, as I think they're unlikely to occur (famous last words?).

I really like your construct. It hurts little to throw in the following "unlikely" errorlevel checks, because you are looking for a zero return for success now. Your second 'JREPL' and mine using /JMATCH seem interchangeable for this verification.

Code: Select all

:test 
echo %1 > in.txt
call jrepl "a.c" "abc" /f in.txt /o out.txt && exit /b 0
IF errorlevel 3 Exit /b 3
IF errorlevel 2 Exit /b 2
call jrepl "a.c" $0 /jmatch /f in.txt > nul && exit /b 0
echo 'a.c' not found (input file contains '%1').
Exit /b 1

John A.

[dbenham]

It seems to me that knowing whether the search term has been found is more important than knowing whether an identical (or effectively identical, in the case of regular expressions) term has been substituted. But that may be a bias because of the particular application I have in mind: if a file doesn't have a revision date, it's an error, but if the old revision date is the same as the new, I don't care.

I would have liked to have implemented that feature, but it is problematic. The replace method that is central to the entire utility does not report whether a match was found. It does not even report whether a change was made. The only way I can detect a change is by comparing the before and after strings after the replace has finished.

I could detect when a match is found by using a carefully designed function as the replacement argument, but that would break much of the other standard functionality that is dependent on not using a function.

So changing the behavior as you suggest would require a major rewrite - not something that I am interested in doing.


Dave Benham

[Mike D]

I would have liked to have implemented that feature, but it is problematic. The replace method that is central to the entire utility does not report whether a match was found. It does not even report whether a change was made. The only way I can detect a change is by comparing the before and after strings after the replace has finished.

Thanks for the explanation. I'm happy with the workaround I'm using.

Some information on the meaning of 'change' in the documentation would be helpful.

There's another minor problem in the documentation: the two links to msdn.microsoft.com for regex syntax are obsolete. The first no longer exists (but can be found on the Internet Archive), and the second still exists, but contains a message saying that it's obsolete. If this is deliberate (i.e., if jrepl doesn't conform to the latest specification), this should be stated.

[Squashman]

Both links worked for me.

[Mike D]

Both links worked for me.

You're right. I don't know what happened the first time. I'm sure I copied the URL correctly, because it worked when I pasted it at the Internet Archive.

Nevertheless, both sites say 'This documentation is archived and is not being maintained', and have links to the 'Recommended Version'.

Here are the current versions.
https://msdn.microsoft.com/en-us/library/ae5bf541(v=vs.100).aspx
https://msdn.microsoft.com/en-us/library/efy6s3e6(v=vs.100).aspx