Add a line of text to a specific line in a file

Sorry, the for statement got broken up...


@echo off
type nul>file.tmp
for /f "delims=" %%i in (file.txt) do (echo %%i>>file.tmp) & if %%i==test1 echo test1-1>>file.tmp
del file.txt
ren file.tmp file.txt

echo %%i>>file.tmp  on the line that ends with the number 2 will echo the line to the screen with errors ( nothing) going to file.tmp

Also, the & is parsed as belonging to the FOR loop so it may not do what it needs until after the loop finished with the file,  I haven't checked.  If it does that, try ^& and change
     echo %%i>>file.tmp  
to
     >>file.tmp  echo %%i
and that shorter program might be quite nifty.

Good Luck,
2K
(\o/)

The & does not terminate a statement, so the parser treats it as part of the statement within the do context. I have tested it and it does work (at least for XP/2000).

Here's batch file that uses a technique from Billious to process and keep the blank lines in a file:

@echo off

set _t1=Y

if exist _temp2.dat del _temp2.dat > NUL
find /N /V "" file.txt > _temp1.dat

for /f "delims=" %%f in (_temp1.dat) do call :PROCESS %%f

del _temp1.dat>NUL
echo _temp2.dat has results of conversion

set _t=
goto EXIT

:PROCESS

set _t=%~1

if "%_t1%"=="" goto LOOP

set _t1=
goto EXIT

:LOOP

if "%_t:~0,1%"=="]" goto TESTIT

set _t=%_t:~1%
goto LOOP

:TESTIT

set _t=%_t:~1%

if "%_t%"=="" goto EMPTYLINE

echo %_t%>>_temp2.dat

if %_t%==test1 echo test1-1>>_temp2.dat
goto EXIT

:EMPTYLINE
echo.>>_temp2.dat
goto EXIT

:EXIT

Good Luck,
Steve

<<<
     echo %_t%>>_temp2.dat
>>>
This could fail.

With all due respect to Billious, Steve, Seth, Microsoft examples - (I take that back - MS does this too, but with all the resources at their disposal they have no excuse) - and everyone else who codes this way - it's less than 100% accurate,  and the example files given in this question fall squarely in the set of data that could cause this line to fail.



At some point in future changes to the data, the user might add lines:
     new test line 1
     new test line 2
Then at some time in the :PROCESS %_t% will be "new test line 1"
So the parser will build the expanded line as
     echo new test line 1>>_temp2.dat
Now it's time to set up the redirect - according to this line, stdout (channel 1) is to go to a file.  The data to send is:
     new test line
That line of output is changed, but not because the program wanted it.  It simply does not realize the parser setup redirection on that line as it was directed, instead of assuming which channel to redirect as it needed to on other lines.
Also at some time in the :PROCESS %_t% will be "new test line 2"
So the parser will build the expanded line as
     echo new test line 2>>_temp2.dat
Now it's time to set up the redirect - according to this line, stderr (channel 2) is to go to a file.  If this is running in a visible window, the user will see
     new test line
and the errors of that echo (there are no errors here) will go to the file.  That line of output is effectively deleted, although all of the logic above does NOT indicate it should be.  Well, the program does not think it was deleted, but it simply does not realize the parser redirected that line differently than the rest.

This line has no such side-effects, since any possible number at the end of lines cannot be accidentally mistaken for part of the redirect directive.
     >>_temp2.dat echo %_t%


Hope this helps,
2K
(\o/)

But doesn't the parser convert the >> to 1>> anyways so that can't happen?

Oh, my aching head,  I'm so confused.

This was a real problem I prooved on an Old box years ago (95 or DOS 6).  Since then I've prooved on NT/2000/XP that trailing spaces followed by redirects still cause problems as before.  That's only if trailing spaces matter to the data, and because old timers used to add space to prevent this parser problem.  
I just now checked and see you are correct, on both NT and 2K the parser has corrected this by changing ">>filename.ext" to " 1>>filename.ext" and the interpreter correctly restrips that last added space from the output.  9X/ME?  I don't know but is moot to this question since they don't do "FOR /f" anyway.  Lines typed with a single digit hard coded and separated by white space are the only ones that still affect redirection.

So Steve's code is solid and also preserves empty lines which none of our other stuff did.

Two retractions in one day,  I think I'll quit while I'm behind.

Thanks Seth for keeping me straight and teaching me something.

2K
(\o/)

Thanx guys!

K_2K your script worked superbly. I modified it a bit with this

:: if string exists stop processing
for /f "delims=" %%K in ( file.txt ) do (if "%%K"=="test1-1" goto eof)

so should the batch file run via a login script the string will not be inserted again.

Thanx again.

Nice addition.  The data file is too short to notice the difference in speed, but this might be a bit faster:

:: if string exists stop processing
>nul findstr /b /e "test1-1"  file.txt && echo eof


We could also add a flag and check in :addlines to delay the new addition until the line after the target is seen not to be "test1-1" avoid reading the file twice.  Caching makes that almost pointless, and that also would create a possible un-needed temp file on every logon, actually taking longer than two file reads.

Enjoy,
2K
(\o/)