Sometimes I need to change the order of an executable command that only shares the name. Let me show you a simple example:
λ where find
C:\Windows\System32\find.exe
C:\Program Files\Git\usr\bin\find.exe
C:\cygwin64\bin\find.exe
On this case, the Windows's 'find' command is called instead of the other two (GNU findutils). My question is quite simple: which is the right way to change the order or set one of them as the first preference?
Go to the environment variables definition of Windows and copy the existing entry for PATH. Create a new variable named BASEPATH and put all entries into it that do not belong to the list of paths where find.exe can be found.
Now create a file called fwin.cmd and put it somewhere on the PATH. The content of that file will look like this:
#echo off
SET PATH=C:\windows\system32;%BASEPATH%
ECHO Set path to search tools like find in Windows own folder
Create two files fgit.cmd and fcyg.cmd and change the PATH accordingly.
From time to time additionally installed applications will change your PATH. If this is the case you will need to add the new entries to the BASEPATH.
Depending on which find.exe you want, open a command line shell of Windows and call the corresponding cmd file. The path set by the batch will be local to the open shell, once you close it the setting will be gone.
You could also address the wanted find.exe directly but this means more typing and is probably not what you want:
dir C:\ /S | C:\Windows\System32\find.exe foo
I solved this by going in the environment variable, search for all path where your exe is and move up and down depending on the preferred order.
Of course this will affect other exe !!!
For this example below I add to move up and down in the system variables PATH and mypath.
C:\Users\duser > where sort
C:\Windows\System32\sort.exe
C:\Program Files\Git\usr\bin\sort.exe
to get
C:\Users\duser > where sort
C:\Program Files\Git\usr\bin\sort.exe
C:\Windows\System32\sort.exe
Using the following code
REGEDIT /E C:\output.reg
A registry dump file is created in C directory. It overwrites automatically when a file with the same name exists. When I try changing the output directory to relative path like this
REGEDIT /E output.reg
it wouldn't work.
No file is created but processing takes just as long as usually. Which code can export the whole registry using relative path?
Like requested, the .bat code including debug code:
ECHO %CD%
REGEDIT /E output.reg
PAUSE
Command line output:
C:\Users\Username\Desktop\New_folder>ECHO C:\Users\Username\Desktop\New_folder
C:\Users\Username\Desktop\New_folder
C:\Users\Username\Desktop\New_folder>REGEDIT /E output.reg
C:\Users\Username\Desktop\New_folder>PAUSE
Press any key to exit . . .
Folder before (and after) .bat file execution:
The syntax of the command given in your question is already fine. If you supply a relative path for the output file name then the file will be created relative to the current working directory. This is easily verified from an interactive command prompt.
Whatever is going wrong with your batch script, the problem is not as you have currently surmised. Some of the more obvious explanations include:
The working directory is not what you think it is. Verify it by adding debug code to your script to emit the working directory.
The file is locked for some reason and so regedit cannot write to the file.
You don't have sufficient rights to write to the working directory.
Update
Thanks a lot for your question update. I tried to re-create your scenario (I'm on Windows 7 but I doubt that matters) and indeed I find the same issue as you. The command works fine from an interactive console window, but not when executing in a batch script.
I've no idea why this is, but here a simple enough workaround is to supply a full path:
REGEDIT /E %cd%\output.reg
after downloaded scala 2.10.2 for windows, and run scala I met such error:
"错误: 找不到或无法加载主类 scala.tools.nsc.MainGenericRunner"
which means "error: can't find or load main class scala.tools.nsc.MainGenericRunner". So I check the scala.bat for reasons, and I found such function:
:set_home
set _BIN_DIR=
for %%i in (%~sf0) do set _BIN_DIR=%_BIN_DIR%%%~dpsi
echo in set_home: %_BIN_DIR%
set _SCALA_HOME=%_BIN_DIR%..
goto :eof
After this function the _SCALA_HOME become D:\program files\scala\files\scala\bin\.., which is obviously wrong. Anyway, after setting _SCALA_HOME to be right path the error fixed. However, do any one knows what %~sf0 and %%~dpsi mean and what this function is really trying to do ?
Thank you!
thank you #gourlaysama
I finally found the real reason：execute the following code and you can see the result is :
for %%i in (%~sf0) do (
echo "%%"i is: %%i
echo sf0 is : %%~dpsi
set _BIN_DIR=%_BIN_DIR%%%~dpsi
)
output:
"%"i is: D:\program
sf0 is : D:\
"%"i is: files\scala\bin\scala.bat
sf0 is : D:\program files\scala\bin\files\scala\bin\
so the malfunction is result from the extra space between program files !
Those weird variables are called parameter extensions. they allow you to interpret a variable as a path to a file/directory and directly resolve things from that path.
For example, if %1 is a path to a file dir123456\file.txt,
%~f1 is the fully qualified path to file.txt,
%~p1 is the path to the containing directory dir123456,
%~s1 is the path in short name format dir123~1\file.txt,
and many others...
Also, %0 is always set to the path of the currently running script. So:
%~fs0 is the fully qualified path, in short name format, to the current script,
%%~dpsi is the manual expansion of the FOR variable %%i to a drive letter (d option) followed by the path the containing folder (p option), in short format (s option).
Now, this weird looking block of code is a workaround for KB833431 in which the %~dps0 command does not give you the path to the folder of the current script (in short format) although it should. This was fixed in XP SP2.
It seems to be reconstructing manually the fully qualified path to the scala bin directory from the fully qualified path to scala.bat, and then just getting that directory's parent, which should be a valid _SCALA_HOME.
If you are trying to create an environmental variable that doesn’t let you include spaces in the directory, you need to use Window’s shortened pathname.
Instead of “C:\Program Files\scala…”, use “C:\Progra~1\scala…”.
Instead of “C:\Program Files (x86)\scala…”, use “C:\Progra~2\scala…”.
OTHERWISE,
This guy found the solution:
https://issues.scala-lang.org/browse/SI-7821
Solution:
To make the changes he talks about to the batch files, download Notepad++
Then right-click on NotePad++ and select "Run as Administrator" or "Run as PowerBroker Administrator".
Open a new file in NotePad++
Navigate to your scala/bin/scala.bat file directory and select scala.bat
Change the code to what the above link says. So the final result should be this:
Make the changes to :add_cpath and :set_home for all the .bat files inside the scala/bin folder.
Now open command prompt and type "scala -version" or just "scala"
I got the same error after I installed Scala in the new volume formatted by Windows 10.
Workaround is to install Scala to the path without spaces. e.g. D:\scala
scala.bat uses 8.3 filenames to set up _SCALA_HOME, but 8.3 filename generation on NTFS volumes can be disabled by option (and it seems default now).
To check whether 8.3 filename generation is enabled, run dir /x and see if short file/folder names are displayed beside long names.
C:\>dir /x
2016/04/19 08:26 <DIR> PROGRA~1 Program Files
D:\>dir /x
2016/04/19 14:38 <DIR> Program Files
Or use fsutil 8dot3name command in the administrator command prompt (Replace D: with your installation drive. TechNet documentation):
fsutil 8dot3name query D:
I'm working with installshield and have a group of batch files that I want to run as part of the install process. Instead of executing each batch file from installshield I want to create one batch file that executes all of the batch files.
The issue I have is that the calling batch file sits two directories up from the others. When the batch file tries to call the others they fail to run because they can not find the resources that they need. It seems that when they are executed from the batch file two directories up they are for some reason using the relative path of the calling batch file. Is my assumption correct?
One of the batch files that I am calling is a batch file to star an h2 database the call looks like this:
call h2\bin\h2.bat
If I go to the /h2/bin directory in a command prompt the h2.bat runs fine but once I run it from the calling batch file this is the error that I get.
Error: Could not find or load main class org.h2.tools.Console
How do I call one batch file from another without using the calling batch files path?
Explanation
It seems that when they are executed from the batch file two
directories up they are for some reason using the relative path of the
calling batch file. Is my assumption correct?
Yes your assumption is correct. Calling a batch file will not change the current working directory. The main batch file will be found because you are providing the correct relative path, but all the other relative paths will be seen from the perspective of your current working directory, not from the directory that contains the main batch file.
%~dp0 is your friend, it yields the drive letter and path to the batch file containing that character sequence. Use it as a basis for relative paths and your batch files will work no matter who calls them from where.
Example:
Fictitious h2.bat that won't work:
#echo off
h2.exe start
Working h2.bat:
#echo off
"%~dp0\h2.exe" start
See What does %~dp0 mean, and how does it work? for more explanations on %~dp0
Try setting the directory:
cd ht\bin\
call h2.bat
cd %HOMEPATH%
REM just reset to where ever you were before.
If that doesn't work, try using the C:// prefix in your path. That might/might not work.
Good Luck!
Suppose current .bat file is running in C drive and you want to run .bat file placed in D: directory then in first .bat write.
D:
cd "D:/folder/folder2/"
call batFile.bat
It might be because you don't have permission. M facing the same problem and i found the solution like this -
Right click on your task than properties.
In properties click on General tab and then click on 'User Group or User' and select appropriate user.
Or create a another bat file to call your bat file and schedule that file. you can create the bat file like this -
open Notepad and give your original bat file path and then call bat file with name like -
D:
cd "E:/ABC/FirstJob/main/"
call main_run.bat
Now save this file with .bat extension.
if your bat file is correct, try cmd command as below and hit enter(tried in windows 10):
"\h2.bat"
e.g: "C:\Users..\bin\h2.bat"
I tried :
pushd h2\bin\
call h2.bat
=> It 's okay.
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%