Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 154
  • Last Modified:

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
0
teiwaz
Asked:
teiwaz
1 Solution
 
TezdreadCommented:
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?
0
 
Eagle6990Commented:
What is !FullPath!  

0
 
teiwazAuthor Commented:
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
0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
oBdACommented:
That's mainly because the "::" construction actually isn't a comment.
A real comment starts with "REM"; the "::" construction is usually used because a line starting with a colon is considered a label, and it's ignored by the parser when processing it--unlike the REM lines, which are processed (turn the echo on, and you'll see it). That saves a bit of time. The double colon :: is, as far as I know, just the common way to designate this as a remark; using a single colon will work as well (in fact, if you start your "remarked" lines either with a single colon, or with a REM, the error will disappear as well).
Why exactly it's happening, I can't tell; that's hidden in the mysterious ways the parser works.
Another way to get rid of long bracket constructions is to use the batch version of a subroutine with "call :label" (enter "help call" for more information).

@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 (
  set Count=%%i
  call :process1
)
for /L %%i IN (1,1,10) Do call :process2 %%i
EndLocal
Goto :leave

:process1
Echo Count is %Count%
Echo before comment
:: Build the parameter replacement command for sed for this parameter
:: Special Case 1: CmdDir
echo after comment
echo.  
goto :eof

:process2
set Count=%1
Echo Count is %Count%
Echo before comment
:: Build the parameter replacement command for sed for this parameter
:: Special Case 1: CmdDir
echo after comment
echo.  
goto :eof

:leave
0
 
teiwazAuthor Commented:
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
0
 
oBdACommented:
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.
0
 
teiwazAuthor Commented:
Thanks for the hlep oBda!
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now