Something like: (This is an example)
call :sub
echo comes first.
goto end
:sub (
echo This part
)
:end
Maybe? If so, what would be the proper way to format it?
I'm aware that I can just call .bat files, but I'd prefer to keep this whole thing in one program.
I'd like this to be accessible throughout multiple parts of the program, so a regular call wouldn't suffice because I want the program to go back to wher it left off each time this is called.
Very close.
Using call :label you can indeed call the same batch file as a separate process, as if it were a subscript. Using goto :eof you can return control to the main script, which will continue at the place it was.
It should also work when the subscript just ends, so, your code should actually work, except for the parentheses, which are invalid the way you use them. Just remove them and you script should work. It should echo:
This part
comes first.
Related
This question already has answers here:
Where does GOTO :EOF return to?
(4 answers)
Closed 8 months ago.
I have a batch file which is performing a series of functions for each item in a file. It's running correctly, however, for some reason, it's performing the operation for the last line in the file twice. Can anyone help me determine why? This is the first for loop I've made on my own, so I'm sure I've made some mistakes.
for /F "tokens=*" %%A in (nations.txt) do (
set "nationname=%%A"
call :ageofdiscovery
)
Point of clarification, what I am trying to do is call each and every line of "nations.txt" one at a time, storing them as a variable, then performing an elaborate series of operations using that variable, before moving on to the next line, and running through the whole of "nations.txt". The idea is to allow the script to work for an arbitrary number of loops, so as to make the script more flexible (It's a text generator, creating histories for fantasy kingdoms).
If there is no problem with the for loop, could someone explain why it's repeating the last output? I have an exit command after the loop, so it shouldn't be executing the script again, and it also has the same random generated output for the repeated last line.
EDIT: As requested, the current contents of nations.txt is:
Nation1
Nation2
Nation3
Nation4
As for the batch script itself, it's 2,134 lines long (and runs perfectly fine with a hard-coded version of the nation selection system. I'm retrofitting code here). I'm unsure of what, or where, any problems could be occurring. I also know that people here do not want me to share the entire script. I will do as requested in relation to the script itself.
The best guess for your observed phenomenon is that your function is defined directly after your loop (you don't show that important detail).
for /F "tokens=*" %%A in (nations.txt) do (
set "nationname=%%A"
call :ageofdiscovery
)
:ageofdiscovery
echo %nationname%
In that case, the function code will be executed after the loop is finished, because batch-files don't have a concept of functions, they only know labels.
It can be easily fixed by an exit /b or goto :eof
for /F "tokens=*" %%A in (nations.txt) do (
set "nationname=%%A"
call :ageofdiscovery
)
exit /b
:ageofdiscovery
echo %nationname%
To chcek if file is loaded or not, I load its contents using:
set /p filevar=file.txt
and check if var is empty:
if "%filevar%"="" exit
When script chceks file with multiple lines, execution of script stops, so i suppose that chcecking fails. Why script fails? How to perform such check properely?
Firstly, you've got the syntax of your set /p command messed up. As it is, it will prompt the user with the text "file.txt". I think what you mean is
set /p "filevar=" <file.txt
You should also use the /b switch with exit to prevent the console window from closing if your script is run from the command line.
But yeah, as jeb states, to check whether left equals right, either use == or equ. Or, as dbenham reminds me, if you're checking for an empty value, you can also use if not defined.
if "%filevar%"=="" exit /b
if "%filevar%" equ "" exit /b
if not defined filevar exit /b
All three statements will have the same result1.
In a console window, enter help if for more information.
1 It's worth mentioning that, while those three if statements have the same result outside of a parenthetical code block, only the third one will work reliably within parentheses (such as in a for loop). The first two would need delayed expansion to work properly if used within the same code block as %filevar% is set.
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:\MyFolder\MyFiles
Mybatfile.bat
Copy afile toHere
or
CD:\MyFolder\MyFiles
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?
As others have said, CALL is the normal way to call another bat file within a .bat and return to the caller.
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.
call is necessary for .bat or .cmd files, else the control will not return to the caller.
For exe files it isn't required.
Start isn't the same as call, it creates a new cmd.exe instance, so it can run a called batch file asynchronosly
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
Okay, I actually didn't even really think about the fact that if you call a batch (regardless of the 'type', i.e. '.bat', or '.cmd') that it won't return if you don't use call.
I've been using call myself though for a different reason that I am actually pretty surprised that no one else has brought up. Maybe I missed it. MAYBE I'M THE ONLY ONE IN THE WORLD WHO KNOWS!! :O
Probably not, but I'm going to drop this knowledge off here because it's super useful.
If you use call you can use binary logic operators to decide how to proceed based on the ERRORLEVEL result. In fact, I always was flabbergasted on how && and || existed in DOS and COULDN'T be used this way. Well, that's why.
The easiest way to test this is to create a return.cmd with notepad, or from the command prompt like so:
c:\> type con >return.cmd
You will now notice the cursor goes down to the next line and hangs. Enter:
#exit /B %1
And then hit ENTER, and then CTRL-Z and that file will be created. Good! You may now feel free to try the following two examples:
call return.cmd 0 && echo Huzzah! A Complete Success! (Or cover up...)
call return.cmd 123 || echo Oops! Something happened. You can check ERRORLEVEL if you want the tinest amount of additional information possible.
So what? Well, run them again with the 0 and the 123 swapped and you should see that the messages DON'T print.
Maybe this multi-line example will make more sense. I use this all the time:
call return.cmd 0 && #(
echo Batch says it completed successfully^^!
) || #(
echo Batch completed, but returned a 'falsey' value of sort.
call echo The specific value returned was: %ERRORLEVEL%
)
(Note the 'call' in the || section before the second 'echo'. I believe this is how people got around not having delayed expansion back in the day. If you DO have delayed expansion enabled (via. setlocal EnableDelayedExpansion inside a batch OR launch a command prompt with cmd /v:on then you can just do !ERRORLEVEL!.)
... This is where I have to apologize and say if you have if ERRORLEVEL trauma in your past you should stop reading. I get it. Trust me. I thought about paying someone on fiverr to remotely type this for me, but for completeness sake I'm just going to take one for the team and mention that you can also do the following to check errorlevel:
if ERRORLEVEL 123 #echo QUICK! MOTHERS, COVER YOUR CHILDREN'S EYES! FINGERS ARE BEING UNDONE! :'(
If you've never typed that before then GOOD! You will live longer without having to read up why exactly you aren't getting the results you expect. Cruel is the word you're looking for, not 'quirky'.
The important part that I really want to get across however is that if you try this and DON'T use 'call' it will ALWAYS execute the 'true' branch. Try it for yourself!
If I'm missing something, or you know a better way to do this, please let me know. I love learning stuff like this!
Additional information I mentioned:
I have known for quite some time that you can put redirects BEFORE commands like so:
>nul echo. This won't be displayed!
But I accidentally discovered the other day by being a dumdum that you can apparently also do:
echo A B>file.txt C
And was REALLY surprised to find a file.txt which consisted of "A B C". It appears yo can place them ANYWHERE, even inside the command. I've never seen anyone do this, nor mention it, but I HAVE seen people mention that you can prefix a line with them.
Maybe it's a bug exclusive to Windows 10 or something. If you have another version and wanna try it out and let me know I'd be interested in what you find out.
Stay nerdy!
I understand how to call nested batch files from within a parent file using the call command, as there are plenty of resources on that:
CALL
CALL (SS64)
Bat file termination
However, I don't understand why calling another batch file from another terminates the parent.
For a less abstract example, suppose I have a batch file that "links" together separate batch files, and I erroneously didn't prepend call to each line:
foo.bat
bar.bat
This would only execute foo.bat and then exit. To correctly execute both commands, I would have to prepend call before each statement:
call foo.bat
call bar.bat
Why does the first functionality still exist? Why hasn't it been changed? I noticed that call was introduced in MS-DOS 3.3, which was released in the late 1980s, so is this functionality still here for reverse compatibility?
I can't think of any (practical) usages of it, but perhaps I'm too used to "new" programming techniques.
DOS used simple text processing (back when you had things like FILES=20 in config.sys to allow 20 file handles), so opened the file, read the next line, closed the file, then executed the line just read. If the file called another, then the processing continued with that file, so only 1 file handle would be required for a batch file.
Until Microsoft put in the call command, there was no way to get back to the original file (without using tricks like giving the name of the previous file as a parameter, and using temporary files to let the original batch file know it had dome some processing, and could then GOTO the next part of the file).
As Sean Cheshire wrote, it's necessary for backward compatibility.
But starting a batch file from a batch file without using CALL does not terminate the parent!
It looks that way, as the parent normally will not executed further after the second batch exits.
But using a call before starting the second.bat, will show that the first batch isn't terminated.
parent.bat
echo parent.bat
call :myLabel
echo back in parent.bat main
exit /b
:myLabel
second.bat & echo back in parent.bat
exit /b
second.bat
echo second.bat
exit /b
I use here the the secpond.bat & echo back ... to avoid another bug/feature of cmd.exe.
If you use second.bat without any extras it will start second.bat AND jump to the label :myLabel in second.bat!
Call is basically saying "go execute this other batch file, and then come back here and continue". It has been there since DOS 3.3 or so, and if it were removed now would break all backward-compatibility (which is why people are still using batch scripts). It can also be used to branch to :link locations.
For info on the use and syntax (for future reference for others), you can see this MS TechNet link
If you need new functionality, use CMD scripts or PowerShell scripts instead.
Hello stackoverflow community,
I am writing a batch file to do some automatic computer maintenance and have included several antivirus applications. For some reason, the third "if not" statement is never reached.
:AV
REM MSE
if not '%MSE%'=='' (
Echo Scanning for viruses using Microsoft Security Essentials.
Echo.
%MSE% -Scan -ScanType 1
Echo.
GOTO Defrag
)
REM AVG
if not '%AVG%'=='' (
Echo Scanning for viruses using AVG.
Echo.
%AVG% /COMP /QT /TRASH
Echo.
GOTO Defrag
)
REM NOD32
if not '%NOD32%'==''(
Echo Scanning for viruses using NOD32.
Echo.
if '%NOD32%'=='' GOTO NOD32NotFound
%NOD32% /aind /auto /log-file="%userprofile%\Desktop\Scan_Results.txt"
Echo.
GOTO Defrag
)
REM If all else fails...
GOTO AVNotFound
Currently, there are three blocks of codes, one for each antivirus program. Each block of code is executed only when the variable %AVG% %MSE% or %NOD32% is not empty, meaning they point to a valid file. I assign the variables using the code:
if exist "%programfiles(x86)%\AVG\AVG2012\avgscana.exe" set AVG="%programfiles(x86)%\AVG\AVG2012\avgscana.exe"
All three blocks of code works perfectly, nothing is wrong with the coding. The problem is that whatever the third block is, it never executes. So in the current example, the blocks of code go in the order of MSE, AVG, and NOD32. NOD32's block of code does not execute because it's the third block. Conversely, if I cut and paste the blocks into another order with AVG's block of code being the third block, it would not execute.
Any ideas?
Any suggestions?
Edited for clarification.
You're missing a space in the line:
if not '%NOD32%'==''(
Try:
if not '%NOD32%'=='' (
When I tried the script this line caused a failure. After changing the line, it worked.
Are the variables %MSE%, %AVG% or %NOD32% batch files? If yes, you will need to invoke them using "call" instead (for example call %AVG%)
If you call a batch file from another, the first one will exit after executing the 2nd one, unless it is called with "call".
Do any of your %AVG%, %NOD32%, or %MSE% variables have brackets in them? Could they be in the C:\Program Files (x86)\ path? A bracket will close the branch prematurely.
Place quotes around the executable part of the commands, for example:
"%MSE%" -Scan -ScanType 1