Windows批处理文件 - 批处理文件在需要一段时间才能完成的命令后中途停止执行

Question

Following are the contents of the file "vs.bat"

call "C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"

call path.bat

dea usev bis 

cd ana

call b-env-i.bat

When I execute this batch file, execution stops after the following step.

dea usev bis

Can anyone please help in pointing out what went wrong here and how I can get all the commands to execute. Note that the aforementioned command (dea usev bis) works fine (both in the batch and if executed separately). dea is the name of the executable and "usv bis" are runtime parameters to the "dea" exe.

I'm running Windows 7.

---

Clarification:

When I run vs.bat, after the third call "dea usev bis" has executed successfully, the batch file stops executing further. That is both the following calls (which are part of VS.bat) don't get executed

cd ana

call b-env-i.bat

Note that the call "dea usev bis" takes around 20 secs to execute, both when run individually and when run as part of the script.

---

Update:

I've tried paxdiablo's suggestions, with the following results:

[C:\dea]for %i in (dea.cmd) do @echo %~$PATH:i
ECHO is on.

[C:\dea]for %i in (dea.bat) do @echo %~$PATH:i
ECHO is on.

[C:\dea]for %i in (dea.exe) do @echo %~$PATH:i
C:\dea\bin\dea.exe

[C:\dea]where dea.exe
C:\dea\bin\dea.exe
C:\dea\bin\dea.exe.1
C:\dea\bin\dea.exe.ia64

When I run it explicitly via the following, I still encounter the same issue

c:\dea\bin\dea.exe usev bis

And, as I said earlier, changing the script to call dea does not fix the issue either.

Is there anything else that I can try?

Answer 1

It looks like you're trying to call another batch/script file which, if you leave off call , will simply be chained to rather than called (chained to, in this context, means it doesn't return). I'd suggest changing that line to:

call dea usev bis

By way of example, consider the scripts go2.cmd :

@echo off
echo %1

and go.cmd :

@echo off
call go2 1
go2 2
echo 3

Executing go will only give you:

1
2

because the go2 2 line chains to, rather than calls that script. The call go2 1 line, however, works fine.

And, even if you have a dea.exe file, that does not necessarily mean it's the one being run. Your script calls dea so leaves the choice as to what actually gets run to the shell (searching the path, trying different extensions and so on).

To check whether or not the thing you're actually calling is a batch file or not, you can do the following. First, execute the following commends:

echo %PATH%
for %i in (dea.cmd) do @echo %~$PATH:i
for %i in (dea.bat) do @echo %~$PATH:i
for %i in (dea.exe) do @echo %~$PATH:i

(or I think you can just use where dea* if you're running Win 7+, see here for details).

This will show you if there is a dea.cmd/bat/exe in your path, and tell you where in the path the relevant directories are. If there is a script version, it may exist in the path before the exe version. You can simply examine your %PATH% environment variable to figure out which directory comes first.

Second, if you have the exe in c:\\dea\\bin , try running that explicitly from your script with:

c:\dea\bin\dea.exe usev bis

If that returns okay, it adds support to the fact a script version is being used instead.

Thirdly, you could just change the script as suggested (add call ) and see if that fixes it. If it is referencing a script, that will fix it.

---

If none of those work (and this appears to be the case based on your response that dea is definitely an exe file), you need to start looking into exactly where the failure occurs. This can be done by placing an echo statement in between every single line so that you can see what's causing the issue. In other words, something like:

echo DEBUG a & time <nul:
call "C:\Program Files (x86)\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat"
echo DEBUG b & time <nul:
call path.bat
echo DEBUG c & time <nul:
dea usev bis 
echo DEBUG d & time <nul:
cd ana
echo DEBUG e & time <nul:
call b-env-i.bat
echo DEBUG f & time <nul:

That will both give you timings for the things that do work and hopefully make it obvious what's not working.