I am trying to factor out a piece of a batch file that sets an environment variable to another batch file. This piece is somewhat involved and I would rather not repeat it in multiple batch files. I won't over-complicate this post with the actual code I'm trying to run in the nested batch file, but will provide a simple example that shows what I'm trying to do and reproduces the problem.
Batch1.cmd
cmd.exe /c setvar.cmd abc def
set abc
setvar.cmd
set var=%1
set val=%2
set %var%=%val%
The error returned for "set abc" in Batch1.cmd is this:
Environment variable abc not defined
I imagine cmd.exe starts up a new environment, because on return to Batch1.cmd, the variable does not exist.
Is there a way I can nest a batch file and keep the environment it creates?
The environment block is not shared between processes. As you are starting a new cmd instance a separate environment block is created, changed and destroyed before returning the control to the current batch file, that will not see any change as it was done in a different process.
Use call setvar.cmd abc def to start the nested batch file in the current process.
Use the setx <var> <val> command to set an environment variable more persistently. For example:
setx WEBCAM_ADDR 192.168.0.101
(Note: There is NO equals sign (=) as with the regular set command)
I just went through this issue, trying to run batch files from windows. This is better than having to write, say, a configuration file somewhere...
Related
A way to run multiple programs in a bat file.
Objective
Distribute a software with GDAL as a dependency.
To do that I have downloaded gdal binaries from GIS Internals. The downloaded data has a .bat file to set environment variables. It uses set command to set the environment variables.
As per my limited knowledge in windows bash scripting, I understand that the environment variables set by set are limited to current command prompt itself and are reset when a new command prompt is launched.
Also, is it true that a calling a batch file from a batch file launches new command prompt which when closes doesn't affect the next command called in the parent script.
There is another issue here - will the environment variables affect the process created (such as calling gdal_translate) by a Java program? If it doesn't, then there is no point in setting local environment variable.
Final Requirement:
How to use the environment variables set in another batch file (called from a batch file) in the next line of the parent batch file, without using setx?
If you use the CALL command to run the batch file as specified in the accepted answer on the question you linked to, then the environment variables will pass up to the parent batch file.
There are three times where this is not true:
When using SETX neither the parent nor child batch file will get the environment variables.
When using SETLOCAL and ENDLOCAL inside the child batch file the parent batch file will not get the environment variables.
When running the child batch file using start or cmd.exe /c.
So long as you run your Java application in the same environment (i.e. the same batch file), it will pick up the same environment variables. You can verify this with an application like Process Explorer.
Running set _kjhgkjshdgkjhdfg=TEST before running a .jar file resulted in the screenshot below using any of:
javaw -jar jarfile.jar
cmd /c javaw -jar jarfile.jar
start cmd /c javaw -jar jarfile.jar
I have a program named go.exe, and I pass it a file name example so that it can make a log file named example_golog.txt.
The problem here is that I want to only call the executable without explicitly giving a filename or making a user have to give a file name.
My solution to this was to name a system variable called GO whose value is go.exe %~n0. What's wrong with this is instead of the %~n0 part getting the file name of the batch file that called it, my go.exe file just makes a text file called %~n0_golog.txt.
Is there any way around this so that %~n0 will do it's magic in the batch files that call it in go.exe %~n0?
EDIT:
My system variable:
Name: GO
Value: go %~n0
My test.bat file:
#echo on
%GO%
pause
When I run test.bat, the %~n0 does not expand out.
So instead of test_golog.txt being made, %~n0_golog.txt is made
In your batch file, you can call it to dereference the variable.
echo %go% will report go %~n0.
call echo %go% will report go test (from a batch file named test).
You can use whatever other sets you need from there.
I have a very simple Windows .BAT file:
set PATH=c:\xxx;%PATH%
call foo.pl
set VAR=true
I thought "call" will start a new batch process, without affecting the current one. However, the batch file exited immediately after the foo.pl finished executing. The set VAR=true has never been called.
Is there a way to fix it?
foo.pl is not a batch file, it is a Perl script.
So you need to use
path c:\xxx;%PATH%
"Path to\Folder With\perl.exe" "foo.pl"
rem Additional batch code executed after Perl script execution finished.
In other words you have to run the console application perl.exe best with full path, or with just perl.exe if program files folder of Perl is not the same on all computers on which this batch file is used and hopefully PATH contains also the directory containing perl.exe.
If you specify on a command line or in a batch file just foo.pl, Windows looks in Windows registry which application is associated with .pl for action Open. If there is such a file association, Windows runs this application in a separate process like when using command start.
So using call foo.pl is like using start foo.pl.
PATH is not only an environment variable, but also an interal command written for changing the value of environment variable PATH at any time within a batch file. This is the reason why I removed set from first line. It is better to use internal command path for modifying environment variable PATH.
I'm performing a mass build (1000+) projects. I call a batch file that calls another batch file that contains a long list of calls to project builds. The problems is, after a few projects, the process stops and says "The input line is too long". I did some research and found that the path environment vars are probably changing and therefore becoming too long. How can I reset the path variable between each of the build calls? Or is there another way I can solve this problem?
A simple solution is that in the batch file which modifies PATH or in one of the parent batch files you insert the line
set InitialPath=%PATH%
And later when the project is built another a line is inserted
PATH=%InitialPath%
A small batch file demonstrating this simple solution:
#echo off
rem Remember initial value of environment variable PATH.
set InitialPath=%PATH%
rem Environment variable PATH is modified to include a compiler directory.
PATH=C:\Program Files (x86)\MyCompiler\bin;%PATH%
rem Do here whatever must be done with modified PATH.
echo %PATH%
rem Restore the initial value of environment variable PATH.
PATH=%InitialPath%
echo %PATH%
rem Optionally the environment variable InitialPath is removed finally.
set InitialPath=
I've set an system environment variable called find which points to a batch script. I did this so that in Win command prompt i could type %find% and it would execute my script. It works the only problem is it only works once, my script takes a parameter or requires user input (have tried both), and then it is as if the %find% is temporarily overwritten, and the %find% of course no longer works, until i reopen the command window. Basically it works once and that's it!
How can i make it work every time? i want to execute my script using the environment variable over and over again at will without reloading the command window.
Thanks.
I created a batch script with the following code:
#ECHO off
echo hello
and added a environmental variable called TEST that points to the script. I have no problem executing the script using the environmental variable multiple times.
Can you please provide some information or code of what your script does?
Remember that find is a MS-supplied utility.
Try using a different name. And show us your batch - even possibly describe what happens when it "no longer works." Games of 20-questions are tedious.
The problem is that the Batch script uses a variable with the same name, so after it run for the first time the variable value is overwritten and no longer works. To prevent this to happen, insert a setlocal command at beginning of the Batch file; this way, when the script ends all variables are reset to the values they had before the script run. This method also delete all new variables defined in the Batch script, so it keep the environment clean.
If your intention is to override the behavior of the existing find.exe utility, you could add the location of the script to the global path variable before your System32 folder (where find.exe is located). For example, let's say your script is C:\Scripts\find.bat. If your path variable is currently set to this:
%SystemRoot%\system32;%SystemRoot%
...then you would change it to this:
C:\Scripts;%SystemRoot%\system32;%SystemRoot%
Beware though... doing this could break other scripts that use the find command (if they don't use the absolute path to find.exe).
If you are just wanting an easy way to run your alternate find command, you could just give it a different name as the others have suggested, then add it to the end of the path or place it in the System32 folder. That would save you from having to type the percent signs at least.