Related
The Anaconda command prompt looks like normal windows command prompt and its start menu shortcut traces back to the cmd.exe file on windows in the C:\Windows\System32 directory, so I know it is just an instance of the command prompt with certain other characteristics or features. I am curious as to what all these other aspects are.
When I click on properties of the "Anaconda Prompt" shortcut, the target is "%windir%\System32\cmd.exe" /K" C:\ProgramData\Anaconda3\Scripts\activate.bat C:\ProgramData\Anaconda3 so it has some extra arguments. In those arguments is the difference between opening a vanilla command prompt and an Anaconda.
Breaking down these commands, the /k option appears to be described here and here to mean run the command and return to the prompt, although those references refer to a lower case /k.
The next argument points to a bat file to activate an Anaconda script. Then it passes a path to a directory called "Anaconda3". I am fairly certain the path it passes as the final arg means it wants this path to be accessible as if it were in the user or system path environmental variable. Python.exe (Python 3) is in this directory, as well as a _conda.exe and an important Scripts folder, so if we don't have our python in the system or user path, this is how it is found, I am fairly certain.
Back to the .bat file, this does a lot of things. I always though bats were binaries, because of how they acted on the system, but they're really just like Bash Scripts for Windows. They are human readable and mine is as follows:
#set "_args1=%1"
#set _args1_first=%_args1:~0,1%
#set _args1_last=%_args1:~-1%
#set _args1_first=%_args1_first:"=+%
#set _args1_last=%_args1_last:"=+%
#set _args1=
#if "%_args1_first%"=="+" if NOT "%_args1_last%"=="+" (
#CALL "%~dp0..\condabin\conda.bat" activate
#GOTO :End
)
#REM This may work if there are spaces in anything in %*
#CALL "%~dp0..\condabin\conda.bat" activate %*
:End
#set _args1_first=
#set _args1_last=
This .bat calls another .bat, "conda.bat", in a nearby directory with it's own code:
#IF NOT DEFINED _CE_CONDA (
#SET _CE_M=
#SET "CONDA_EXE=%~dp0..\Scripts\conda.exe"
)
#IF [%1]==[activate] "%~dp0_conda_activate" %*
#IF [%1]==[deactivate] "%~dp0_conda_activate" %*
#SETLOCAL EnableDelayedExpansion
#IF DEFINED _CE_CONDA (
#REM when _CE_CONDA is defined, we're in develop mode. CONDA_EXE is actually python.exe in the root of the dev env.
FOR %%A IN ("%CONDA_EXE%") DO #SET _sysp=%%~dpA
) ELSE (
#REM This is the standard user case. This script is run in root\condabin.
FOR %%A IN ("%~dp0.") DO #SET _sysp=%%~dpA
IF NOT EXIST "!_sysp!\Scripts\conda.exe" #SET "_sysp=!_sysp!..\"
)
#SET _sysp=!_sysp:~0,-1!
#SET PATH=!_sysp!;!_sysp!\Library\mingw-w64\bin;!_sysp!\Library\usr\bin;!_sysp!\Library\bin;!_sysp!\Scripts;!_sysp!\bin;%PATH%
#SET CONDA_EXES="%CONDA_EXE%" %_CE_M% %_CE_CONDA%
#CALL %CONDA_EXES% %*
#ENDLOCAL
#IF %errorlevel% NEQ 0 EXIT /B %errorlevel%
#IF [%1]==[install] "%~dp0_conda_activate" reactivate
#IF [%1]==[update] "%~dp0_conda_activate" reactivate
#IF [%1]==[upgrade] "%~dp0_conda_activate" reactivate
#IF [%1]==[remove] "%~dp0_conda_activate" reactivate
#IF [%1]==[uninstall] "%~dp0_conda_activate" reactivate
#EXIT /B %errorlevel%
As I expected, when I called the activate.bat file in an ordinary (admin) command prompt, it turned into an Anaconda prompt with the "(base)" prefix before my current path you get when you click the startup shortcut. (base) C:\Users\User>. Interestingly, doing this only seems to work in the regular command prompt, not Git Bash, not WSL, not even Powershell, though there is a separate Powershell launcher that works. In its properties, it has the target:
%windir%\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy ByPass -NoExit -Command "& 'C:\ProgramData\Anaconda3\shell\condabin\conda-hook.ps1' ; conda activate 'C:\ProgramData\Anaconda3' "
And if you run the ps1 file (a powershell like script), it has the same effect of putting you into the conda environment, because you can run the 'conda' command and help instructions appear.
Here is the ps1 code.
$Env:CONDA_EXE = "C:/ProgramData/Anaconda3\Scripts\conda.exe"
$Env:_CE_M = ""
$Env:_CE_CONDA = ""
$Env:_CONDA_ROOT = "C:/ProgramData/Anaconda3"
$Env:_CONDA_EXE = "C:/ProgramData/Anaconda3\Scripts\conda.exe"
Import-Module "$Env:_CONDA_ROOT\shell\condabin\Conda.psm1"
Add-CondaEnvironmentToPrompt
Anyway that's just kind of the background context, which I learned in the last few hour researching, because I wanted to do my homework. I wanted and want to know is what Conda is doing in Windows when you open the Command Prompt through Anaconda. I'm pretty certain it is doing two main things: setting the path to include the C:\ProgramData\Anaconda3 directory, for the session, and activating it's base environment or any other virtual environment you tell it to launch that you may have created through it at some point, but does it do anything else of note?
I ask this not just because I am curious about what's really going on (I am), but I was also hoping to work with Conda in Git Bash and WSL, terminals I really like. I can currently use Conda's Python with them (the only Python on my machine) as it seems to exist independent of the program that installed it and manages packages for it, but I was specifically hoping to use the all the Conda environment management tools inside Git Bash or WSL. After thinking about it, I now don't believe this is possible. From a naive user perspective, one sort of assumes they can run any program anywhere, and that makes sense or would have made sense before we had sub-systems and systems within systems, but from a more aware point of view, Anaconda was installed for Windows and inside the C:\ProgramData\Anaconda3 directory are .exe and .bat files, not Linux/WSL compatible binaries and .sh or .bash files. It's like trying to run Windows_OS>Linux subsystem>Windows_file_again, but it doesn't work like that. WSL and Git Bash don't even have the same path structure somehow. Am I right in my thinking so far?
I enjoy Git Bash and WSL more than Powershell or cmd and I use them a lot for GCC and git. I do most of my coding in VS Code and launch these terminals there. I suppose at best I could install conda for git bash or wsl if such a thing existed, but even then it might not be able to talk to my main Conda or share environments. Otherwise I could either trying using venv for an environment, as that appears to work in these shells through python, or just use the normal command prompt to do everything if I really want to use Conda.
Am I right in my assessments?
Thanks for sticking with me! To get good at something, you have to get to the point where it's all plainly obvious, otherwise you run the risk of being lost and confused at a time you least want to be.
Edit: Now that I'm back at it, I rediscovered my original hurdle: the fact couldn't use Conda's command prompt straight from the VS Code or how to activate it once I booted the normal command prompt. Now I know about the .bat startup script at least and could in theory activate it that way each time, but it's kind of awkward, or I could launch a prompt externally and navigate to my working directory, but that's clumsy too. I forgot that this was my first blocker, and on a related note I had similar issues with x64 Native Tools (a Visual Studio based command prompt). I wondered what that was as well, why it looked like an independent terminal but I couldn't launch it in VS Code.
For WSL, yes you are right. Running the conda that you installed for windows would be the same as trying to run any other program that you installed for windows -> it will fail because the binaries are not compatible. You would probably be able to install the linux version there, but as you pointed out, that is not what you want.
For git bash, the solution is more simple than you might think. You can set it up so that you can "talk"to your windows installed conda. Yes, you will need to have the equivalent setup to what you have already discovered for cmd and powershell, but conda already has everything you need to set it up.
Assuming your installation is at C:\Users\foo\miniconda3\, from your git bash, do:
/c/Users/foo/miniconda3/Scripts/activate
conda init bash
this will modify your bash_profile to automatically set up conda for use from git bash
Some clarifications:
I now don't believe this is possible. From a naive user perspective, one sort of assumes they can run any program anywhere, and that makes sense or would have made sense before we had sub-systems and systems within systems, but from a more aware point of view, Anaconda was installed for Windows and inside the C:\ProgramData\Anaconda3 directory are .exe and .bat files, not Linux/WSL compatible binaries and .sh or .bash files. It's like trying to run Windows_OS>Linux subsystem>Windows_file_again, but it doesn't work like that. WSL and Git Bash don't even have the same path structure somehow
WSL, as you have pointed out, is a subsystem and, since wsl 2 runs a real linux kernel. It naturally follows that, as you have said, it is not possible to run windows binaries from it.
Git bash however, is not a subsystem at all. Instead, it is a port of bash for windows. That means when you are in your git bash, you are still within your windows environment. Only the syntax for paths and commands is different (see above commands I have provided), but you are still in the same system.
If you look at the file
C:\Users\foo\miniconda3\Scripts\activate
you will also see that it is a normal .sh script that calls conda.sh at
C:\Users\a-fjochhe\miniconda3\etc\profile.d\conda.sh
So ana/miniconda does indeed come with a set of sh scripts that you can use from a bash terminal in Windows
Please help me troubleshoot the following problem I am facing with my app.
I have written my own shell for windows, named gsh, which currently implements most of the CMD.EXE functionality. So far all activities I perform under GSH are identical to CMD, except for this issue I have with the NMAKE program.
Here's the test scenario. I have several c++ projects built using 'nmake all' on command prompt. Under CMD, nmake runs smoothly (meaning it builds all the targets that need to be built). Under GSH, however, namke builds the first set of targets ( i.e. all *.obj for *.cpp) but not the *.exe that depend on the newly bult *.obj. I have to run 'nmake all' a second time to built the *.exe.
If I run 'nmake clean' before 'nmake all' then all targets are built fine.
I am 100% sure makefile is correct. I have checked all environment variables between GSH and CMD and they are the same. I have also checked the dates on the produced files and they look fine(meaning dates on produced files are newer, and date of *.exe is older than the date of the depending *.obj). I can also confirm that while 'nmake all' is running, it does not invoke another copy of the shell (to do its tasks, which might caused a problem to nmake). Note: On a complex makefile, I can see nmake issuing system(...) function which invokes the shell pointed by ComSpec env var, which I can direct it to either GSH or CMD, without any apparent change in behavior.
Thank you all for any ideas you might have on the root cause of the above.
cheers!, gt
I have Windows 7 and tried to use the 'make' command but 'make' is not recognized as an internal or external command.
I did Start -> cmd -> run -> make, which outputs:
'make' is not recognized as an internal or external command,operable program or batch file.
Then I typed 'mingw32-make' instead of 'make' (Start -> cmd -> run -> mingw32-make) and I get the same output:
'mingw32-make' is not recognized as an internal or external command,operable program or batch file.
What shall I do next in order to fix this problem?
In Windows10, I solved this issue by adding C:\MinGW\bin to Path and then called it using MinGW32-make not make.
Your problem is most likely that the shell does not know where to find your make program. If you want to use it from "anywhere", then you must do this, or else you will need to add the full path each time you want to call it, which is quite cumbersome. For instance:
"c:\program files\gnuwin32\bin\make.exe" option1=thisvalue option2=thatvalue
This is to be taken as an example, it used to look like something like this on XP, I can't say on W7. But gnuwin32 used to provide useful "linux-world" packages for Windows. Check details on your provider for make.
So to avoid entering the path, you can add the path to your PATH environment variable. You will find this easily.
To make sure it is registered by the OS, open a console (run cmd.exe) and entering $PATH should give you a list of default pathes. Check that the location of your make program is there.
This is an old question, but none of the answers here provide enough context for a beginner to choose which one to pick.
What is make?
make is a traditional Unix utility which reads a Makefile to decide what programs to run to reach a particular goal. Typically, that goal is to build a piece of software from a set of source files and libraries; but make is general enough to be used for various other tasks, too, like assembling a PDF from a collection of TeX source files, or retrieving the newest versions of each of a list of web pages.
Besides encapsulating the steps to reach an individual target, make reduces processing time by avoiding to re-execute steps which are already complete. It does this by comparing time stamps between dependencies; if A depends on B but A already exists and is newer than B, there is no need to make A. Of course, in order for this to work properly, the Makefile needs to document all such dependencies.
A: B
commands to produce A from B
Notice that the indentation needs to consist of a literal tab character. This is a common beginner mistake.
Common Versions of make
The original make was rather pedestrian. Its lineage continues to this day into BSD make, from which nmake is derived. Roughly speaking, this version provides the make functionality defined by POSIX, with a few minor enhancements and variations.
GNU make, by contrast, significantly extends the formalism, to the point where a GNU Makefile is unlikely to work with other versions (or occasionally even older versions of GNU make). There is a convention to call such files GNUmakefile instead of Makefile, but this convention is widely ignored, especially on platforms like Linux where GNU make is the de facto standard make.
Telltale signs that a Makefile uses GNU make conventions are the use of := instead of = for variable assignments (though this is not exclusively a GNU feature) and a plethora of functions like $(shell ...), $(foreach ...), $(patsubst ...) etc.
So Which Do I Need?
Well, it really depends on what you are hoping to accomplish.
If the software you are hoping to build has a vcproj file or similar, you probably want to use that instead, and not try to use make at all.
In the general case, MinGW make is a Windows port of GNU make for Windows, It should generally cope with any Makefile you throw at it.
If you know the software was written to use nmake and you already have it installed, or it is easy for you to obtain, maybe go with that.
You should understand that if the software was not written for, or explicitly ported to, Windows, it is unlikely to compile without significant modifications. In this scenario, getting make to run is the least of your problems, and you will need a good understanding of the differences between the original platform and Windows to have a chance of pulling it off yourself.
In some more detail, if the Makefile contains Unix commands like grep or curl or yacc then your system needs to have those commands installed, too. But quite apart from that, C or C++ (or more generally, source code in any language) which was written for a different platform might simply not work - at all, or as expected (which is often worse) - on Windows.
First make sure you have MinGW installed.
From MinGW installation manager check if you have the mingw32-make package installed.
Check if you have added the MinGW bin folder to your PATH. type PATH in your command line and look for the folder. Or on windows 10 go to Control Panel\System and Security\System --> Advanced system settings --> Environment Variables --> System Variables find Path variable, select, Edit and check if it is there. If not just add it!
As explained here, create a new file in any of your PATH folders. For example create mingwstartup.bat in the MinGW bin folder. write the line doskey make=mingw32-make.exe inside, save and close it.
open Registry Editor by running regedit. As explained here in HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER go to \Software\Microsoft\Command Processor right click on the right panel New --> Expandable String Value and name it AutoRun. double click and enter the path to your .bat file as the Value data (e.g. "C:\MinGW\bin\mingwstartup.bat") the result should look like this:
now every time you open a new terminal make command will run the mingw32-make.exe. I hope it helps.
P.S. If you don't want to see the commands of the .bat file to be printed out to the terminal put #echo off at the top of the batch file.
If you already have MinGW installed in Windows 7, just simply do the following:
Make another copy of C:\MinGW\bin\mingw32-make.exe file in the same folder.
Rename the file name from mingw32-make.exe to make.exe.
Run make command again.
Tested working in my laptop for above steps.
For window-10 resolved error- make' is not recognized as an internal or external command.
Download MinGW - Minimalist GNU for Windows from here https://sourceforge.net/projects/mingw/
install it
While installation mark all basic setup packages like shown in image
Apply changes
After completion of installation
copy C:\MinGW\bin
paste in system variable
Open MyComputer properties and follow as shown in image
You may also need to install this
https://sourceforge.net/projects/gnuwin32/
As other answers already suggested, you must have MinGW installed. The additional part is to add the following two folders to the PATH environment variable.
C:\MinGW\bin
C:\MinGW\msys\1.0\bin
Obviously, adjust the path based on where you installed MinGW. Also, dont forget to open a new command line terminal.
'make' is a command for UNIX/Linux. Instead of it, use 'nmake' command in MS Windows. Or you'd better use an emulator like CYGWIN.
Search for make.exe using the search feature, when found, note down the absolute path to the file. You can do that by right-clicking on the filename in the search result and then properties, or open location folder (not sure of the exact wording, I'm not using an English locale).
When you open the command line console (cmd) instead of typing make, type the whole path and name, e.g. C:\Windows\System32\java (this is for java...).
Alternatively, if you don't want to provide the full path each time, then you have to possibilities:
make C:\Windows\System32\ the current working directory, using cd at cmd level.
add C:\Windows\System32\ to you PATH environment variable.
Refs:
use full path: http://technet.microsoft.com/en-us/magazine/ff678296.aspx
cd: http://technet.microsoft.com/en-us/library/cc731237.aspx
PATH: http://technet.microsoft.com/en-us/library/bb490963.aspx
I am using windows 8. I had the same problem. I added the path "C:\MinGW\bin" to system environment variable named 'path' then it worked. May be, you can try the same. Hope it'll help!
try download & run my bat code
======run 'cmd' as admin 2 use 'setx'=====
setx scoop "C:\Users%username%\scoop" /M
echo %scoop%
setx scoopApps "%scoop%\apps" /M
echo %scoopApps%
scoop install make
=======Phase 3: Create the makePath environment variable===
setx makePath "%scoopApps%/make" /M
echo %makePath%
setx makeBin "%makePath%/Bin" /M
echo %makeBin%
setx Path "%Path%;%makeBin%" /M
echo %Path%
use mingw32-make instead of cmake in windows
I will be concise.
The command FOR /F %i IN (C:\Version.txt) DO #set Version=%i works perfectly fine in cmd.exe to read the text of the file into a variable. but whenever I put that line into a prebuild event in Visual Studio it says Exited with code 255.
On http://msdn.microsoft.com/en-us/library/windows/desktop/ms681382(v=vs.85).aspx I found that 0xFF / 255 means: The extended attributes are inconsistent..
How do I use that command in a pre build event?
Many thanks.
The correct syntax is
FOR /F %%i IN (C:\Version.txt) DO #set Version=%%i
However this will not work as you epxect: VS spawns a cmd.exe process to execute build events, meaning that if you set a variable it is local to that cmd.exe only, hence the rest of your build will not have access to Version.
Luckily there are much better alternatives than batch files: if you're using VS2010 or higher, the project files are msbuild files, so to get all possible versioning things working you just create a common msbuild script to do whatever you need to do with the version (eg create a .res file if it's for C++, or modify the AssemblyInfo.cs for C#) and include it in all your projects.
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%