Solve : XP pro DOS batch file editing?

1.	Solve : XP pro DOS batch file editing?
Answer» ghostdog74 you are a star! Your last suggestion worked like a charm. My 5 test files to be edited all clone beatifully with the 60.0 changed to 50.0 and then back again to 60.0 as many times as I like with no additional spaces and hence no continual increase in file size. Magic! I put a > nul at the end of the cscript line to get round the problem of MICROSOFT's header running up the screen each time that the vb script is called in the FOR DO loop. I have cut and PASTED what I had before this addition here: Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. The nub of the batch file now looks like this: @echo off setlocal enableextensions setlocal enabledelayedexpansion for /f %%x in ('dir /a:-d /s /b') do ( cscript freqconv.vbs %%x %1 %2 > nul ) ) endlocal And the whole lot runs from the dos prompt with: H:\TEST_DIR> VBChgFreq 50.0 60.0 where my batch file is called VBChgFreq An observation is that although this vb script version avoids trailing spaces, my impression is that the process runs more slowly than the all batch file version. So if contrex can crack the DOS batch file problem I may go back to that but hey what an education I have had today. Thanks very much. Regards, Les.Quote from: LesD on June 07, 2007, 08:24:04 AM An observation is that although this vb script version avoids trailing spaces, my impression is that the process runs more slowly than the all batch file version. yes, that's because of the algorithm that is looping over the file. Its not efficient. Its left to you to find out why and improve on it if you are interested. Also, once you become more familiar with vbscript, you will be able to do all in one script, without going through the batch for loop...i guess that would be a bit faster...well....Hi Sidewinder, Thanks for taking another look. The problem I have now is that even with the space removed as you show below I still get an addiitional space on all the unedited lines! Quote from: Sidewinder on June 07, 2007, 04:54:09 AM Code: [Select] echo !input!>> %%x.chg In my adapted version of your original code I did remove all the spaces between input! and the > in the initial belief that this would fix it but it didn't. This bit as shown below is taken from my earlier post above: if %%i==%1 echo !input1!>> %%x.chg if not %%i==%1 ( if not "%%j"=="" echo %%i,%%j>> %%x.chg ) if not %%i==%1 ( if "%%j"=="" echo %%i>> %%x.chg ) Before I did this there were two extra spaces added to the ends of the lines when they were written out again! (The reason for the if statements is to prevent other occurrences of 60.0 in the file being changed too. I forgot to mention this in my first post)! It is a weirdy. Microsoft would probably say, "How could you possibly not want it to work this way"! Regards, Les. Les, I was able to get this to work on XP Home, but on a XP Pro rig, the batch file created the extra space. You may CALL this weirdy but Microsoft would call it a feature. I have no answer to this other than to suggest you go with the Ghostdog solution of a VBScript. In the long run VBScript is a richer language, less cryptic, more intuitive and provides more functionality for complex situations than does batch code. For more info on scripting in Windows check out the Script Center. Good luck. Sidewinder, Ghostdog, Contrex, What can I say other than thanks again for all the help and advice it is much appreciated. I can live with the time it takes the batch file/vb combination to make the CHANGES. This time last WEEK I was faced with 320 files to edit manually so the utility is a vast improvement on that situation. Sidewinder, I am perplexed that the way XP Home processes batch files is different to the way XP Pro does it. I guess we may never know why this is unless Bill Gates joins the forum! Regards, Les.

Answer»

ghostdog74 you are a star!

Your last suggestion worked like a charm.

My 5 test files to be edited all clone beatifully with the 60.0 changed to 50.0 and then back again to 60.0 as many times as I like with no additional spaces and hence no continual increase in file size. Magic!

I put a > nul at the end of the cscript line to get round the problem of MICROSOFT's header running up the screen each time that the vb script is called in the FOR DO loop.

I have cut and PASTED what I had before this addition here:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

The nub of the batch file now looks like this:

@echo off
setlocal enableextensions
setlocal enabledelayedexpansion
for /f %%x in ('dir /a:-d /s /b') do (
cscript freqconv.vbs %%x %1 %2 > nul
)
)
endlocal

And the whole lot runs from the dos prompt with: H:\TEST_DIR> VBChgFreq 50.0 60.0

where my batch file is called VBChgFreq

An observation is that although this vb script version avoids trailing spaces, my impression is that the process runs more slowly than the all batch file version.

So if contrex can crack the DOS batch file problem I may go back to that but hey what an education I have had today.

Thanks very much.

Regards,

Les.Quote from: LesD on June 07, 2007, 08:24:04 AM

An observation is that although this vb script version avoids trailing spaces, my impression is that the process runs more slowly than the all batch file version.

yes, that's because of the algorithm that is looping over the file. Its not efficient. Its left to you to find out why and improve on it if you are interested.
Also, once you become more familiar with vbscript, you will be able to do all in one script, without going through the batch for loop...i guess that would be a bit faster...well....Hi Sidewinder,

Thanks for taking another look.

The problem I have now is that even with the space removed as you show below I still get an addiitional space on all the unedited lines!

Quote from: Sidewinder on June 07, 2007, 04:54:09 AM

Code: [Select] echo !input!>> %%x.chg

In my adapted version of your original code I did remove all the spaces between input! and the > in the initial belief that this would fix it but it didn't.

This bit as shown below is taken from my earlier post above:

if %%i==%1 echo !input1!>> %%x.chg
if not %%i==%1 ( if not "%%j"=="" echo %%i,%%j>> %%x.chg )
if not %%i==%1 ( if "%%j"=="" echo %%i>> %%x.chg )

Before I did this there were two extra spaces added to the ends of the lines when they were written out again!

(The reason for the if statements is to prevent other occurrences of 60.0 in the file being changed too. I forgot to mention this in my first post)!

It is a weirdy. Microsoft would probably say, "How could you possibly not want it to work this way"!

Regards, Les.

Les,

I was able to get this to work on XP Home, but on a XP Pro rig, the batch file created the extra space. You may CALL this weirdy but Microsoft would call it a feature.

I have no answer to this other than to suggest you go with the Ghostdog solution of a VBScript. In the long run VBScript is a richer language, less cryptic, more intuitive and provides more functionality for complex situations than does batch code.

For more info on scripting in Windows check out the Script Center.

Good luck.

Sidewinder, Ghostdog, Contrex,

What can I say other than thanks again for all the help and advice it is much appreciated.

I can live with the time it takes the batch file/vb combination to make the CHANGES. This time last WEEK I was faced with 320 files to edit manually so the utility is a vast improvement on that situation.

Sidewinder,
I am perplexed that the way XP Home processes batch files is different to the way XP Pro does it. I guess we may never know why this is unless Bill Gates joins the forum!

Regards,

Les.

Solve : XP pro DOS batch file editing?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment