|yes, that nailed it! thanks, i'm learning a lot from this kind of problem. the ECHO | (echo followed anywhere after by the pipe symbol) causes the echo to be expanded and only the data after the pipe (including the pipe) gets saved in the prompt-variable. this behaviour is circumvented by use of|
enabledelayedexpansion. but with enab not set. the SET /P
variable retained the pipe as its first char. and everything in front of the pipe disappeared into limbo. then if you try to echo the variable, the variable activates as a command:
@echo off && setlocal
set /p xx=enter:
now, if I enter the following: testing | type foo.txt
at the "enter:" prompt, %xx% becomes: "| type foo.txt"
now if i try to echo the value of %xx%, it looks (to the script interpreter) like: echo | type foo.txt and so %xx% becomes non-displayable via "echo". the only way to display it is to remove the pipe: set xx=%xx:~1% and now it can be echoed.
while this is a minor irritation, what if your user, at a set /p, enters: testing > valdata.xls
eh? there goes your spreadsheet you've been working on for three months!
well, i enabled delayed expansion, and i'll just repost the new code complete to avoid confusion trying to "patch" the original version.
@echo off && setlocal enabledelayedexpansion
for /f %%z in ('find /v /c "" ^< infile.txt') do (set lc=%%z)
set /p aa=replace:
set /p bb=with:
call :getline < infile.txt > newfile
for /L %%n in (1 1 %lc%) do (
set /p xx=
if "!xx!" equ "!aa!" set xx=%bb%
this worked by "defeating" the pipe symbol that was crashing the original version. this shows yet another reason to use enabledelayedexpansion, if a user includes a pipe anywhere in his response to a "set /p", the batch will blow up.
ps: stumbled on another way to capture blank lines, just use 'type filename' like:
for /f "tokens=* delims=" %%a in ('type "%file%"') do echo line is [%%a]