routine to replace special char in string

[cellist]

I found the following routine in an August, 2011 posting by Liviu.

@rem ===================================
:: %1 = env-var holding !%1! input string
:: %2 = character to be replaced n.b. "=" equal sign must be quoted
:: %3 = replacement string, or "" to remove !%2!
:: %4 = env-var to receive the %1:%2=%3 end result

:set.subst.char
if "!errorlevel!"=="%errorlevel%" (
setlocal disabledelayedexpansion
call :set.subst.char.main %*
endlocal & set "%~2=!%~2!"
goto :eof
)
:set.subst.char.main
setlocal enabledelayedexpansion
set "string="
set /a index=0
:set.subst.char.loop
set "char=!%~1:~%index%,1!"
if "!char!"=="" goto :set.subst.char.done
if "!char!"=="%~2" (
set "string=!string!%~3"
) else (
set "string=!string!!char!"
)
set /a index+=1
goto :set.subst.char.loop
:set.subst.char.done
endlocal & set "%~4=%string%"
goto :eof
@rem ===================================

I've tried to use it but I think I'm not sending the correct input
parameters to the routine. Here's my script to call the subroutine:

set invar=c:\ab*\xyz\def*
set replace="*"
set replacewith=""
::set outvar="" ==== tried it with and without this, seems to make
no diff also tried passing the bare word and the variable %outvar
%...no diff
echo call with: invar [invar] replace [%replace%]
replacewith[%replacewith%] outvar [%outvar%]
call "C:\bat\replace-any-char.bat" invar %replace% %replacewith%
outvar
set myout=%outvar%
echo result is [%myout%]

The last few lines echo'd:

C:\Users\Owner>set /a index+=1
C:\Users\Owner>goto :set.subst.char.loop
C:\Users\Owner>set "char=!invar:~15,1!"
C:\Users\Owner>if "!char!" == "" goto :set.subst.char.done
C:\Users\Owner>endlocal & set "outvar=c:\ab\xyz\def"
C:\Users\Owner>goto :eof

The 'endlocal & set "outvar=c:\ab\xyz\def"' shows that the output
string is as expected -- the asterisks have been removed. However,
%outvar% does not contain the output string. It looks like the
setshould be something
like "%outvar%=..." or "!outvar!=..., so I must be
passing that parameter incorrectly. What should it be?

[Liviu]

"cellist" <pwric...@gmail.com> wrote...

>
> I found the following routine in an August, 2011 posting by Liviu.

For reference:
http://groups.google.com/group/alt.msdos.batch.nt/msg/05f18220d0a028ca?hl=en

> I've tried to use it but I think I'm not sending the correct input
> parameters to the routine. Here's my script to call the subroutine:
>
> set invar=c:\ab*\xyz\def*
> set replace="*"
> set replacewith=""

>[...]

> call "C:\bat\replace-any-char.bat" invar %replace% %replacewith%
> outvar

The 'call' above should work, and an "echo %outvar%" right after should
return "c:\ab\xyz\def". It does so here.

Make sure your "C:\bat\replace-any-char.bat" contains just the quoted
code, and no extra "setlocal" at the top (which would make the 'outvar'
assignment local to the .bat).

Liviu

P.S. Also, you can drop the entire 'if "!errorlevel!"=="%errorlevel%"
(...)' block from the posted code, which upon a second look is wrong,
anyway. It doesn't really matter in your case since your echo's indicate
a default disableDelayedExpansion run, so that block is not executed.

[cellist]

On Apr 13, 10:30 pm, "Liviu" <lab...@gmail.c0m> wrote:>
> The 'call' above should work, and an "echo %outvar%" right after should
> return "c:\ab\xyz\def". It does so here.
>
> Make sure your "C:\bat\replace-any-char.bat" contains just the quoted
> code, and no extra "setlocal" at the top (which would make the 'outvar'
> assignment local to the .bat).
>
> Liviu
>
> P.S. Also, you can drop the entire 'if "!errorlevel!"=="%errorlevel%"
> (...)' block from the posted code, which upon a second look is wrong,
> anyway. It doesn't really matter in your case since your echo's indicate
> a default disableDelayedExpansion run, so that block is not executed.

I made dozens -- probably > 100 -- runs trying different
configurations of the output variable and other things. I remember
using SETLOCAL once just to see what difference it would make. When it
didn't "help", I removed it from my script. I honestly don't recall
EVER using SETLOCAL ENABLEDELAYEDEXPANSION or SETLOCAL
DISABLEDELAYEDEXPANSION, but it's possible I might have tried them. In
any event, I'm certain that, if one of them had made a difference for
the better I would have noted it.

I originally used an exact copy of the posted code. When it didn't
become obvious what was going wrong, I added an occasional echo or
pause here and there. So it's possible I might have gummed something
up and made a substantive difference in the code. However, I'm certain
that I removed the extra pauses and echoes and it was still failing.
From time to time, I even completely refreshed the copy of the code I
was making changes to from the original download of the posted code.
(I had it open in my editor for read-only, so I could not have
accidentally changed the my local copy of the posted code.) Of course
it's still possible that I messed up something in the "experimental
code" where I was adding and removing pauses and echoes, etc.

After reading your reply, I reloaded your posted code and compared it
to my local "read only" copy using WinMerge and found only three
differences:

An extra whitespace character after the left paren in [ if "!
errorlevel!"=="%errorlevel%" ( ]
An extra whitespace character at the end of [ setlocal
disabledelayedexpansion ]
An extra whitespace character after the trailing " in [ endlocal
& set "%~4=%string%" ]

I don't know whether any of these could have had an impact on my
testing.

Finally, I closed the command window, which I had been using over and
over for my testing. In the fresh window, my tests no longer fail! I
even tried with each of the three SETLOCAL lines, and none of those
failed either. So I must have introduced the problem in one of the
"slight" changes I made during my testing between refreshes of the
posted code.

Thanks again, Liviu, for the code and I apologize for wasting your
time.

Phil

[foxidrive]

On 14/04/2012 17:20, cellist wrote:
> Finally, I closed the command window, which I had been using over and
> over for my testing. In the fresh window, my tests no longer fail!

Is this XP? Maybe even in later Windows too, there is the 'Random Behaviour Generator' feature of a CMD prompt.

It occurs most often when testing commands and code that generates errors of some kind. Then the CMD prompt does strange things, sometimes until a reboot.


It was probably that 'Random Behaviour Generator' that kicked in and not an error in your editing.


--
Mic

[cellist]

ROFL. I'll plead that I was had by the Windows7 RBG. Seriously, I was
"in the business" for 35 years before retiring, and I don't know how
many times customers told me "I didn't change anything blah-blah-blah
but after I rebooted your product ran fine...". It's nice to be
informed about the face-saving RBG. I hope Liviu gets a laugh out of
this, too.

Phil

[Liviu]

"cellist" <pw...@gmail.com> wrote

>
> Finally, I closed the command window, which I had been using over
> and over for my testing. In the fresh window, my tests no longer fail!

Glad to hear it's sorted out, and I agree with Mic's diagnosis ;-)

Liviu