To “Call” or “Not to Call” a batch file?
Multi tool use
To “Call” or “Not to Call” a batch file?
If from inside a bat file you called another batch file but still had a few remaining operations to complete, how can you make sure that the call to first bat file will after completion or error, will return to the file that called it in the first instance?
Example:
CD:MyFolderMyFiles
Mybatfile.bat
Copy afile toHere
or
CD:MyFolderMyFiles
CALL Mybatfile.bat
COPY afile toHere
What is the difference between using CALL or START or none of them at all? Would this have any impact on whether it would return for the results of the copy command or not?
CALL
START
call
ok, fair , but what is the difference, mechanics behind the scene? and what is START? same as call?
– AltF4_
Feb 6 '13 at 14:55
possible duplicate of Why does calling a nested batch file without prepending "call" to the line exit the parent batch file?
– SeanC
Feb 6 '13 at 18:03
@SeanCheshire - I wouldn't call that a duplicate. The OP primarily wants a mechanism to guarantee a return to the parent, even if there was an error. CALL does not return in the case of fatal syntax error. The linked question does not address this issue at all.
– dbenham
Feb 7 '13 at 15:38
3 Answers
3
As others have said, CALL is the normal way to call another bat file within a .bat and return to the caller.
CALL
However, all batch file processing will cease (control will not return to the caller) if the CALLed batch file has a fatal syntax error, or if the CALLed script terminates with EXIT without the /B option.
You can guarantee control will return to the caller (as long as the console window remains open of course) if you execute the 2nd script via the CMD command.
cmd /c "calledFile.bat"
But this has a limitation that the environment variables set by the called batch will not be preserved upon return.
I'm not aware of a good solution to guarantee return in all cases and preserve environment changes.
If you really need to preserve variables while using CMD, then you can have the "called" script write the variable changes to a temp file, and then have the caller read the temp file and re-establish the variables.
I found the following page rather enlightening on the difference between
cmd /c and CALL: robvanderwoude.com/call.php– Rabarberski
Apr 14 '16 at 14:05
cmd /c
CALL
And no matter you
call, start or just run the second bat, all the environment variables set by the first bat will be available to the second bat.– smwikipedia
May 8 at 6:24
call
start
set
call is necessary for .bat or .cmd files, else the control will not return to the caller.
For exe files it isn't required.
call
Start isn't the same as call, it creates a new cmd.exe instance, so it can run a called batch file asynchronosly
Start
call
I ran into this issue at work just recently and never knew this. +1.
– wootscootinboogie
Jul 26 '15 at 0:23
The `CALL' statement was introduced in MS-DOS 3.3
It is used to call other batch files within a batch file, without aborting the execution of the calling batch file, and using the same environment for both batch files.
So in your case the solution is to use CALL
CALL
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
Yes; you should
call.– Dave Newton
Feb 6 '13 at 14:50