- Batch Read Line From File Into Variable Word
- Batch Read First Line Of File To Variable
- Batch File Set Variable From Text File
Batch Read Line From File Into Variable Word
AGerman wrote:Your code works fine for me. Open your.cir file with a HEX editor and check whether or not the line break is a Windows line break.RegardsaGermanHmm, i only see a linefeed (0A)!I'm on/under W7 and created the launcher.cig file using Notepad.I believe it has to do something with syntax highlighting/language settings.Unbelievable how this could happen, i literally searched all over the internet for hours looking for a solution (facepalm)Thank you so much aGerman (danke sehr), i'll now test it with the correct settings.
Liviu wrote:@aGerman, nice guessing.@©opyit®ight, you may want to check. As long as your text files stay inside NPP you won't notice, since it detects and honors the existing EOLs, but as soon as you leave NPP (such as opening in Notepad, or running as a batch) it's expected that the text files use DOS style CR-LF lines endings.LiviuIt works, and thanks!ps: if you allow me (off-topic): if i would want to have a more feature rich/flexible scripting language, would AutoIT be a good choice?(i just want to start expanding my capabilities and learn/try something new)Again thanks for the help!
Jeb wrote:Btw. Do I said that I'm totally excitedYou're indeed batch-crazy, jebI'm with you jeb - This is fantastic.My favorite part is there is no longer a need to enable and disable delayed expansion with each loop iteration. This makes it MUCH easier for complex logic that requires variables set for one line to be preserved for subsequent lines.But - as a bonus, this technique is actually faster than the old way (I think because there is no need to setlocal/endlocal with each iteration.)I wanted to test the performance so I wrote loops to copy a 50k text file. Useless I know, but it is a good test that easily verifies everything was read correctly. I wanted to test this against the 'traditional' way of reading a text file while preserving empty lines and special characters.- Copy1 uses the new technique, writes entire file at end of outer block.- Copy2 same as Copy1, but writes each line using append - MUCH SLOWER- Copy3 'Traditional method'- Copy4 Same as Copy3, but I wanted to investigate performance of type file find /c /v ' vs. Find /c /v ' file. No difference found.- Copy1a Same as Copy 1, but added unneeded SETLOCAL/ENDLOCAL to show that this is why Copy3/4 are slower than Copy1.I tested each method 10 times.
The new method was roughly twice as fast.The timing macros used in this test are available. Jeb wrote:I find no way of detecting the end of the file with 'set /p', it simply read empty lines.But if you append then a line it reads this immediatelyYes - I had hoped that the%errorlevel% would help. An error is set, but it doesn't differentiate between an exhausted input stream and an empty line. I am mildly surprised that the input stream remains open after exhaustion such that the 'endless' loop terminates upon appending the STOP line. That modifies my understanding of how the input redirection works - thanks.I confirmed that the terminating STOP line does not require the at the end.
Batch Read First Line Of File To Variable
Which raises an interesting question - what if STOP is written character by character and SET /P happens to read the line in the middle. It seems as though the loop should then carry on.I thought of attempting to read the entire file via a GOTO loop, but didn't like the necessity of modifying the file to detect the end.
Batch File Set Variable From Text File
I also assumed it would be slower than a FOR /L loop, even though the FOR /L solution must read the file twice - the 1st time to determine the number of lines.I ran some tests and the GOTO solution is indeed significantly slower. I terminated the test file with::STOP prior to running the test. Code: file='testCall.bat', lines=1686, size=52089copy1=00:00:00.70copy1=00:00:00.70copy1=00:00:00.68copy1=00:00:00.69copy1=00:00:00.70copy1=00:00:01.20copy1=00:00:01.23copy1=00:00:01.20copy1=00:00:00.70copy1=00:00:00.71Comparing files testCall.bat and TESTCALL.BAT.COPY1FC: no differences encounteredcopy2=00:00:05.79copy2=00:00:05.75copy2=00:00:05.75copy2=00:00:05.77copy2=00:00:05.75copy2=00:00:05.77copy2=00:00:05.76copy2=00:00:05.77copy2=00:00:05.73copy2=00:00:05.75Comparing files testCall.bat and TESTCALL.BAT.COPY2FC: no differences encounteredDave Benham. Code: <%file% (for /f 'skip=2'%%i in ('type%file% find /n /v ') do (set 'ln='set /p 'ln='echo(!ln!))%out%And so does aGerman's original suggestion with FINDSTR.2) As often happens with batch programming - the methods that seems like they should be faster are actually slower as the size of the file increases.Once I proved that each method was able to copy properly, I stripped out the copy portion and preserved only the read portion of the code. In this way I was able to time just the code that is necessary to do the read.I tested 6 different methods for reading a text file: 4 using the new SET /P syntax, and two using the 'traditional' FOR /F approach. I did not further test the SET /P approach using a GOTO loop because A) I've already shown it is slower, and B) it requires altering the text file with an appended STOP flag. The read should be non-destructive.For test files to read, I started with one batch file that was approximately 1 kbyte in size and progressively doubled the size until I reached 32k.
I did the same with a file that was approximately 50k and doubled it until I reached 1600k.I tested each of the methods 10 times against the 1k derived test files, and 3 times against the 50k derived files, and averaged the results.I also ran the tests on two different machines.The test code takes 2 arguments:%1 = the test file to read%2 = the number of times to test each methodHere is the test code.