teiwaz
asked on
Error using Set (displayed but not functional error)
I'm writing a batch file to automate running some SQL scripts. It works great. However, echo's an error message every time I call the set command. The command works, and functionally it does not cause any problems, but I'm curious why there is this error (and ideally what I need to do to get rid of it)
The error is:
The system cannot find the drive specified.
This occurs on lines like this one:
Set ParamValue=!FullPath!
Usually this is happening within an If block or a For block.
Any ideas?
Thanks!
Teiwaz
The error is:
The system cannot find the drive specified.
This occurs on lines like this one:
Set ParamValue=!FullPath!
Usually this is happening within an If block or a For block.
Any ideas?
Thanks!
Teiwaz
Not saying that I'll be able to help but could you post the rest of the code to give a clearer picture of what's happening?
What is !FullPath!
ASKER
Sorry for the delay, here is a sample script that has this behaviour.
And !FullPath! is an environment variable that is within a for loop and is using delayed expansion. %FullPath% does not show the value of the environment variable within a For if the value changes within that for block.
While trying to get a script that just shows the error (my full script is rather long), I found out that the error is being caused by a combination of comment lines, not the Set command!
The comments are:
:: Build the parameter replacement command for sed for this parameter
:: Special Case 1: CmdDir
If either of the lines is removed, no error. weird.
Here is the full script:
<start>
:: Weird Error example
@echo off
:: This is an example script showing how a weird error is caused
Echo My System Info
ver
echo.
Setlocal EnableDelayedExpansion
:: An error will be raised here when the script hits the embedded comments
for /L %%i IN (1,1,10) Do (
Echo i is %%i
Echo before comment
:: Build the parameter replacement command for sed for this parameter
:: Special Case 1: CmdDir
echo after comment
echo.
)
EndLocal
Goto :eof
<end>
After you run this, try removing either of the comment lines. Only the combination causes error. Any idea why?
Thanks!
Teiwaz
And !FullPath! is an environment variable that is within a for loop and is using delayed expansion. %FullPath% does not show the value of the environment variable within a For if the value changes within that for block.
While trying to get a script that just shows the error (my full script is rather long), I found out that the error is being caused by a combination of comment lines, not the Set command!
The comments are:
:: Build the parameter replacement command for sed for this parameter
:: Special Case 1: CmdDir
If either of the lines is removed, no error. weird.
Here is the full script:
<start>
:: Weird Error example
@echo off
:: This is an example script showing how a weird error is caused
Echo My System Info
ver
echo.
Setlocal EnableDelayedExpansion
:: An error will be raised here when the script hits the embedded comments
for /L %%i IN (1,1,10) Do (
Echo i is %%i
Echo before comment
:: Build the parameter replacement command for sed for this parameter
:: Special Case 1: CmdDir
echo after comment
echo.
)
EndLocal
Goto :eof
<end>
After you run this, try removing either of the comment lines. Only the combination causes error. Any idea why?
Thanks!
Teiwaz
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Very interesting. So this whole double colon thing for comments is just a short cut that programers have figured out? I read at http://www.ss64.com/nt/rem.html that REM prevents most commands from executing, but double-colon prevent all of them from executing. Looks like that information was not quite correct!
So, in summary, this is happening because:
a) the double-colon commenting style is actually not a comment to the parser but a special case of a label
b) this is caused because of some weird interaction in the parser of a label with in a bracketed set of commands
And this can be fixed by:
- use sub-routines instead of large blocks of code
- try using single colons
- maybe try not having two lines together
That about it?
teiwaz
So, in summary, this is happening because:
a) the double-colon commenting style is actually not a comment to the parser but a special case of a label
b) this is caused because of some weird interaction in the parser of a label with in a bracketed set of commands
And this can be fixed by:
- use sub-routines instead of large blocks of code
- try using single colons
- maybe try not having two lines together
That about it?
teiwaz
When I come to think about it, the double colon is actually an invalid label, since a label should consist of characters after the colon. So it seems to be the combination of a block and two illegal labels that causes the hickup.
And that's about it.
If in doubt, I'd go for the call :label solution, especially in for loops. That's very helpful as well in NT4, where the delayed expansion doesn't exist; you can circumvent this problem by jumping to a subroutine.
And that's about it.
If in doubt, I'd go for the call :label solution, especially in for loops. That's very helpful as well in NT4, where the delayed expansion doesn't exist; you can circumvent this problem by jumping to a subroutine.
ASKER
Thanks for the hlep oBda!