I am building a Windows .bat script to automatically compile and install the Geant4 toolkit from CERN (but my following questions are independent of which of software I want to deal with). What I managed to do so far seems to work OK-ish, but I am not satisfied with how the environment variables are set at the end of the script.
To complete the installation, I have to set up environment variables to indicate the path to required data-sets, and C++ include and library directories (I choose to modify the "PATH" variable for these lasts). I want to set them up for the current script (using set command) and for the next executions (using setx command)
The script I am using now to do that is the following:
REM to get the path to directory where this bat file is executed from.
set G4_bat_file_dir=%~dp0
REM set the environement variables for next cmd runs
REM adding to local (temporary) PATH
set G4dataset_RootDir="%G4_bat_file_dir%\install\share\Geant4-10.4.3\data\"
REM adding environment variables for current and next cmd executions
setx G4dataset_RootDir "%G4_bat_file_dir%\install\share\Geant4-10.4.3\data\"
setx G4ABLADATA %G4dataset_RootDir%\G4ABLA3.1
setx G4ENSDFSTATEDATA %G4dataset_RootDir%\G4ENSDFSTATE2.2
setx G4LEDATA %G4dataset_RootDir%\G4EMLOW7.3
setx G4LEVELGAMMADATA %G4dataset_RootDir%\PhotonEvaporation5.2
setx G4NEUTRONHPDATA %G4dataset_RootDir%\G4NDL4.5
setx G4NEUTRONXSDATA %G4dataset_RootDir%\G4NEUTRONXS1.4
setx G4PIIDATA %G4dataset_RootDir%\G4PII1.3
setx G4RADIOACTIVEDATA %G4dataset_RootDir%\RadioactiveDecay5.2
setx G4REALSURFACEDATA %G4dataset_RootDir%\RealSurface2.1.1
setx G4SAIDXSDATA %G4dataset_RootDir%\G4SAIDDATA1.1
set G4ABLADATA=%G4dataset_RootDir%\G4ABLA3.1
set G4ENSDFSTATEDATA=%G4dataset_RootDir%\G4ENSDFSTATE2.2
set G4LEDATA=%G4dataset_RootDir%\G4EMLOW7.3
set G4LEVELGAMMADATA=%G4dataset_RootDir%\PhotonEvaporation5.2
set G4NEUTRONHPDATA=%G4dataset_RootDir%\G4NDL4.5
set G4NEUTRONXSDATA=%G4dataset_RootDir%\G4NEUTRONXS1.4
set G4PIIDATA=%G4dataset_RootDir%\G4PII1.3
set G4RADIOACTIVEDATA=%G4dataset_RootDir%\RadioactiveDecay5.2
set G4REALSURFACEDATA=%G4dataset_RootDir%\RealSurface2.1.1
set G4SAIDXSDATA=%G4dataset_RootDir%\G4SAIDDATA1.1
setx Geant4_DIR %G4_bat_file_dir%\install\lib\Geant4-10.4.3\
REM adding to PATH the paths to libraries and includes for Qt4 and Geant4.
setx PATH "%G4_bat_file_dir%\install\lib;%G4_bat_file_dir%\install\bin;%G4_bat_file_dir%\xerces-c\instal\bin;%G4_bat_file_dir%\xerces-c\instal\lib;%G4_bat_file_dir%Qt4\install\bin;%G4_bat_file_dir%Qt4\install\lib;%PATH%"
The paths %G4_bat_file_dir%\install\lib;%G4_bat_file_dir%\install\bin;%G4_bat_file_dir%\xerces-c\instal\bin;%G4_bat_file_dir%\xerces-c\instal\lib;%G4_bat_file_dir%Qt4\install\bin;%G4_bat_file_dir%Qt4\install\lib being the ones I want to append.
This is a screenshot of the environment variables set-up I get after running the script 2 times :
http://djienne.free.fr/env.png
This is far from ideal, there several things that I am not happy with:
all the paths in the variables get fully expended, and then also the PATH variable gets too long and I get the error "WARNING: The data being saved is truncated to 1024 characters."
If I run the script twice in a row, it produces duplicates in the PATH entries (and everything above the 1024 characters limit is truncated)
also, if I put this code at the end of my main compilation/installation script it gives the error 'setx' is not recognized as an internal or external command, operable program or batch file. and so the environment variables are not created/modified. But if I run this script as a separate .bat file, it works. So there is something I don't understand.
(I specify that I always do "run as administrator" to run the scripts.)
Thanks in advance for the help.
Following the advice from the comments, I built a batch script launch_visual_studio.bat at the top level of my project, to launch Visual Studio with an updated local PATH. The file contains the code:
#echo off
REM Set the environment
set G4_bat_file_dir=%~dp0
set QTDIR=%G4_bat_file_dir%Qt5\qt-5.6.3\
set QMAKESPEC=win32-msvc2015
set Geant4_DIR=%G4_bat_file_dir%install\lib\Geant4-10.4.3\
REM split into two parts for readability
set PATH=%PATH%;%G4_bat_file_dir%install\bin;%G4_bat_file_dir%install\lib;%G4_bat_file_dir%install\include\Geant4
set PATH=%PATH%;%QTDIR%lib;%QTDIR%bin;%QTDIR%include
REM launch visual studio
"%vs140comntools%..\IDE\devenv.exe"
This works for visual studio 2015, but will be different for other versions.
For the environment variables other than PATH, QTDIR and Geant4_DIR, since they have very specific names (G4ABLADATA, G4ENSDFSTATEDATA, ...), it seems fine to set them permanently using setx, as shown previously.
I'm working in Windows and would like to know if there is a way to remove the current working directory from the path? I understand that this is the default behavior in PowerShell, but I need it to work in batch or at the Windows command-line.
In UNIX, I would just make sure that my $PATH variable not contain .. Is there any way to accomplish this in batch? This is the current behavior:
H:\tmp>dir
Volume in drive H has no label.
Volume Serial Number is E29C-7B61
Directory of H:\tmp
04/27/2018 10:39 AM <DIR> .
04/27/2018 10:39 AM <DIR> ..
04/27/2018 10:40 AM 37 dwk.bat
1 File(s) 37 bytes
2 Dir(s) 987,995,770,880 bytes free
H:\tmp>dwk.bat
dwk.bat has been run.
H:\tmp>
This is the desired behavior:
H:\tmp>dwk.bat
'dwk.bat' is not recognized as an internal or external command,
operable program or batch file.
H:\tmp>.\dwk.bat
dwk.bat has been run.
H:\tmp>
Thanks.
I recommend first reading the answers on Stack Overflow questions:
Where is "START" searching for executables?
What is the reason for '...' is not recognized as an internal or external command, operable program or batch file?
Many thanks to eryksun because of this answer would not exist without his comment on above referenced answer.
Next I recommend reading the Microsoft Developer Network (MSDN) articles:
Naming Files, Paths, and Namespaces
NeedCurrentDirectoryForExePath function
The question can be answered with: Yes, it is possible for desktop applications and batch files on
Windows Vista and all later Windows client versions and
Windows Server 2003 and all later Windows Server versions.
An environment variable with name NoDefaultCurrentDirectoryInExePath must be defined with any value to prevent execution of a script (.bat, .cmd, .vbs, ...) or an application (.com, .exe) stored in current directory without explicitly using .\ as required on Unix/Linux.
The environment variable NoDefaultCurrentDirectoryInExePath can be defined as system variable to turn off searching in current directory for a script or application for all accounts on this machine. But this is surely no good idea as it will result definitely in many applications including installers and uninstallers won't work anymore correct.
The environment variable NoDefaultCurrentDirectoryInExePath can be defined as user variable to turn off searching in current directory for a script or application for processes using this account. But this is surely also no good idea.
But it can make sense to set the environment variable NoDefaultCurrentDirectoryInExePath as local variable in some use cases to turn off searching in current directory for a script or application without explicitly using .\ on Windows versions with kernel function NeedCurrentDirectoryForExePath which cmd.exe calls before searching for a script file or application not containing a backslash \ (or a forward slash /) in file name string.
Example:
#echo off
pushd "%TEMP%"
set "NoDefaultCurrentDirectoryInExePath=0"
echo #echo %%0 executed successfully.>Test1.bat
echo Calling Test1.bat ...
call Test1.bat
echo Calling .\Test1.bat ...
call .\Test1.bat
echo Starting Test1.bat ...
start /wait Test1.bat ^& timeout 5
set "NoDefaultCurrentDirectoryInExePath="
echo Calling again Test1.bat ...
call Test1.bat
del Test1.bat
popd
pause
This batch file executed from within a command prompt window results in output of current console window:
Calling Test1.bat ...
'Test1.bat' is not recognized as an internal or external command,
operable program or batch file.
Calling .\Test1.bat ...
.\Test1.bat executed successfully.
Starting Test1.bat ...
Calling again Test1.bat ...
Test1.bat executed successfully.
Press any key to continue . . .
And during execution of this batch file a second console window is opened with output:
"%TEMP%\Test1.bat" executed successfully.
This second console window is closed automatically after 5 seconds.
The environment variable NoDefaultCurrentDirectoryInExePath is defined with value 0 after setting directory for temporary files as current directory with pushing current directory path on stack. The variable value does not matter because of evaluated is only existence of environment variable and not its value.
Next another batch file with name Test1.bat is created in directory for temporary files which is usually not write-protected for current user as this would cause lots of troubles.
The first approach to call Test1.bat without any path fails because of environment variable NoDefaultCurrentDirectoryInExePath is defined in local environment.
The second call of Test1.bat with relative path .\ is successful despite existence of the environment variable.
The command START ignores NoDefaultCurrentDirectoryInExePath as proven by this batch file.
Then the environment variable NoDefaultCurrentDirectoryInExePath is deleted to restore original Windows behavior.
The second approach to call Test1.bat without any path is successful now.
Finally the created Test1.bat is deleted and initial current directory is restored as current directory.
It is of course not possible to prevent execution of command DIR which is not a script file or an executable. It is an internal command of cmd.exe – Windows Command Processor – respectively of powershell.exe – Windows PowerShell.
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.
My requirement is to get the path two levels up from where the batch file is being executed:
Suppose my batch file is located at:
D:\testfolder\system\tools\configuration task\conf.bat
I use the following code in batch file:
SET BATCH_FILE_DIR=%~dp0
echo %BATCH_FILE_DIR%
SET PATH_TWO_LEVELS_UP=?????
I tried searching over the net, but could not find anything useful.
For me, something should replace ????? which would set,
PATH_TWO_LEVELS_UP to D:\testfolder\system\
Also, it should work for UNC Path. Suppose if the same batch file is available at:
\\pc-dummy\testfolder\system\tools\configuration task\conf.bat
If open the above location in explorer and double click on batch file,
the variable PATH_TWO_LEVELS_UP should be set to \\pc-dummy\testfolder\system\
What should come in place of ????? that would work for local drive as well as for UNC Paths
for %%a in ("%~dp0..\..") do set "PATH_TWO_LEVELS_UP=%%~fa"
echo %PATH_TWO_LEVELS_UP%
Get a reference to the required folder using a for command and set the variable to the full path to the referenced folder
I would like to know what are the approaches that you use to manage the executables in your system. For example I have almost everything accessible through the command line, but now I come to the limit of the path string, so i can't add any more dir.
So what do you recommend?
A long time ago, I tried to use softLinks of the executables in a Dir that belonged to the path, but that approach didn't work.
Throw the "executable only" to a known Dir,has the problems that almost any application require a set of files, so this also is bad.
Throw the executable and all his files to a known Dir, mmm this will work, but the possibility to get a conflict in the name of the files is very very high.
Create a HardLink? i don't know. What do you think?
This will parse your %PATH% environment variable and convert each directory to its shortname equivalent and then piece it all back together:
#echo off
SET MyPath=%PATH%
echo %MyPath%
echo --
setlocal EnableDelayedExpansion
SET TempPath="%MyPath:;=";"%"
SET var=
FOR %%a IN (%TempPath%) DO (
IF exist %%~sa (
SET "var=!var!;%%~sa"
) ELSE (
echo %%a does not exist
)
)
echo --
echo !var:~1!
Take the output and update the PATH variable in environment variables.
One way I can think of is to use other environment variables to store partial paths; for example, if you have
C:\this_is_a\long_path\that_appears\in_multiple_places\subdir1;
C:\this_is_a\long_path\that_appears\in_multiple_places\subdir2;
then you can create a new environment variable such as
SET P1=C:\this_is_a\long_path\that_appears\in_multiple_places
after which your original paths become
%P1%\subdir1;
%P1%\subdir2;
EDIT: Another option is to create a bin directory that holds .bat files that point to the appropriate .exe files.
EDIT 2: Ben Voigt's comment to another answer mentions that using other environment variables as suggested might not reduce the length of %PATH% because they would be expanded prior to being stored. This may be true and I have not tested for it. Another option though is to use 8dot3 forms for longer directory names, for example C:\Program Files is typically equivalent to C:\PROGRA~1. You can use dir /x to see the shorter names.
EDIT 3: This simple test leads me to believe Ben Voigt is right.
set test1=hello
set test2=%test1%hello
set test1=bye
echo %test2%
At the end of this, you see output hellohello rather than byehello.
EDIT 4: In case you decide to use batch files to eliminate certain paths from %PATH%, you might be concerned about how to pass on arguments from your batch file to your executable such that the process is transparent (i.e., you won't notice any difference between calling the batch file and calling the executable). I don't have a whole lot of experience writing batch files, but this seems to work fine.
#echo off
rem This batch file points to an executable of the same name
rem that is located in another directory. Specify the directory
rem here:
set actualdir=c:\this_is\an_example_path
rem You do not need to change anything that follows.
set actualfile=%0
set args=%1
:beginloop
if "%1" == "" goto endloop
shift
set args=%args% %1
goto beginloop
:endloop
%actualdir%\%actualfile% %args%
As a general rule, you should be careful about running batch files from the internet, since you can do all sorts of things with batch files such as formatting your hard drive. If you don't trust the code above (which I wrote), you can test it by replacing the line
%actualdir%\%actualfile% %args%
with
echo %actualdir%\%actualfile% %args%
Ideally you should know exactly what every line does before you run it.
if you are using windows vista or higher, you can make a symbolic link to the folder. for example:
mklink /d C:\pf "C:\Program Files"
would make a link so c:\pf would be your program files folder. I shaved off 300 characters from my path by using this trick.
In case anyone's interested...
I find I never really need all those paths at once, so I create a bunch of "initialization" batch files which modify the path accordingly.
For example, if I wanted to do some C++ development in Eclipse, I would do:
> initmingw
> initeclipse
> eclipse
This is also handy for avoiding conflicts between executables with the same name (such as the C++ and D compilers, which both have a make.exe).
My batch files typically look like this:
#echo off
set PATH=C:\Path\To\My\Stuff1;%PATH%
set PATH=C:\Path\To\My\Stuff2;%PATH%
I find this approach relatively clean and have yet to run into any problems with it.
I generally don't have to worry about this (I haven't run into a path size limit - I don't even know what that is on modern Windows systems), but here's what I might do to avoid putting a program's directory in the path:
most command line utilities get thrown into a c:\util directory that's on the path
otherwise, I'll add a simple cmd/batch file to the c:\util directory that looks something like:
#"c:\program files\whereever\foo.exe" %*
which essentially creates an alias for the command. It's not necessarily perfect. Some programs really insist on being in the path (that's pretty rare nowadays), and other programs that try to invoke it might not find it properly. But for most uses it works well.
But generally, I haven't had to worry about avoiding adding directories to the path.
Another idea: Use DIR /X to determine the short names generated for non-8dot3 file
names. Then use these in your %PATH%.
For example, 'C:\Program Files' becomes 'C:\PROGRA~1'.
USe the App Path registry key instead of the path variable for application-specific paths:
http://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx
I wrote and use on a every-time basis a standard stream (stdin/stderr/stdout) & exit code PROXY program (called dispatcher https://github.com/131/dispatcher)
All CLI program i use (node, php, python, git, svn, rsync, plink ...) i'm using are actually the same exe file (around 10kb, that i just name differently), that i put in the same directory. A dummy static clear text file do the "proxy file name to real exe mapping".
Dispatcher use low level Process management win32 API to be absolutly transparent.
Using this software, i only do have ONE additionnal directory set in my PATH for all programs i might use.
Creating a folder c:\bin adding to your path and hardlinking like you said could shorten the string. Maybe add a variable pf to system vars with value c:\Program Files then replace c:\Program Files with %pf% in path.
Edit:
Create a virtual drive.
subst p: "c:\program files"
I follow these steps to make the entries manageable:
Created different users for different combination of software packages usage.
Example: (a) Created a user web for making available all the web development software; (b) Created a user database for making available all the database and data warehousing software packages. Remember some software may create more than one entry. Or sometime I break this into oracle specific and MSSQL specific and oracle specific users. I put MySQL/PostgreSQL, tomcat, wamp, xamp all into the user account webr.
If possible install common packages like office, photoshop, .. as system specific available for all users and special packages as user specific. Of course I had to log into different users and install them. Not all software may provide this option. If "install for this user only" option is not available, install it for the whole system.
I avoid installing programs in to the folder Program File (x86) or in to Program File. I always install into the base directory. For example MySQL 64 bit goes into "C:\mysql64" and MySQL 32 bit goes into "C:\mysql" folder. I always assume adding a suffix 64 only for 64bit software. If no suffix, then it is a 32 bit. I follow the same thing to Java and others. This way my path will be shorter, not including "C:\Program File (x86)". For some software the configuration file may need to be edited to show where exactly the .exe file is. Only program that demands to be installed into "C:\Program File (x86)" will be installed into that folder. Always I remember to shorten the names. I avoid version number like tomcat/release/version-2.5.0.3 such details. If I need to the know version, I create a file by name version and put it into the tomcat folder. In general shorten the link as much as possible.
Include any batch to replace abbreviated link to the path, if all the above steps passed the Windows limit.
Then Log into usage specific (mobile application, or database/data warehousing or web-development.. ..) user and do the relevant tasks.
You can also create virtual windows within windows. As long as you have one licensed OS copy, creating multiple virtual windows with same key is possible. You can put packages specific for a particular task in that machine. You have to launch separate VM each time. Some memory intensive packages like 3D animation movie makers all should be put into the main machine, not into VM as VM will have only a part of the RAM available for its use. It is a pain to boot each VM though.
The solutions above only work if you can trim down your path. In my case, that wasn't really an option, and it was a hassle to have to run a script every time I opened a command prompt. So I wrote a simple script that runs automatically when opening the command prompt, and appends the contents of a text file to your path.
There are also some contexts where having this script run breaks things (say, in a github or cygwin shell), so I also added a file that contains a list of paths that, if the command prompt is started in them, the path variable isn't changed via the startup script that normally updates the path.
#echo off
:: Modify these to the actual paths of these two files
set dontSetupFile=C:\Users\Yams\Dontsetup.txt
set pathFile=C:\Users\Yams\Path.txt
:: Retrieve the current path (for determining whether or not we should append to our path)
set curDir=%cd%
:: Be done if the current path is listed in the dontSetupFile
SetLocal EnableDelayedExpansion
for /F "delims=" %%i in (%dontSetupFile%) do (
if "%%i"=="%curDir%" GOTO AllDone
)
:: Append the pathFile to our current PATH
set pathAppend=
for /F "delims=" %%i in (%pathFile%) do (set pathAppend=!pathAppend!%%i)
set PATH=%PATH%;%pathAppend%
:: The only way to actually modify a command prompt's path via a batch file is by starting
:: up another command prompt window. So we will do this, however, if this script is
:: automatically called on startup of any command prompt window, it will infinately
:: recurse and bad things will happen.
:: If we already ran, we are done
if "%yams%"=="onion" GOTO AllDone
:: Otherwise, flag that we just ran, and then start up a new command prompt window
:: with this flag set
set yams=onion
cmd \K set PATH=%PATH%;
:: When that command prompt exits, it will load back up this command prompt window, and
:: then the user will need to exit out of this as well. This causes this window to
:: automatically exit once the cmd it just spawned is closed.
exit()
:: Path is set up, we are done!
:AllDone
#echo on
And Path.txt will look something like
C:\Program Files (x86)\Google\google_appengine;
C:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;
C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;
C:\Program Files\Microsoft SQL Server\110\Tools\Binn;
C:\Program Files\Microsoft DNX\Dnvm;
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit;
While Dontsetup.txt will look something like
C:\Program Files (x86)\Windows Kits\8.0\Windows Performance Toolkit
C:\Program Files (x86)\Git\cmd
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin
To make this run automatically on startup, open regedit, navigate to HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Command Processor, then right click on the right and press new -> Multi-String Value. Name it AutoRun. Set it's value to
C:\Users\Yams\setUpPath.bat
or wherever else you stored the batch file above.
Didn't try it, but will splitting PATH in parts work and joining them in final variable work?
Example initially let's say you have something like
PATH={LONGPATH1};{LONGPATH2};....{2048th char}....{LONGPATH_N-1};{LONGPATH_N}
Instead you create:
_PATH1 = {LONGPATH1};{LONGPATH2};....{2048 char}
_PATH2 = {2049th char}...{LONGPATH_N-1};{LONGPATH_N}
rem // may be more parts
PATH = %_PATH1%;%_PATH2%