If I wanted to compile code in java, I go to environment variables and set the PATH variable to the bin of the jdk on my computer. Now my command prompt recognizes commands like "javac" and "java" and I can compile/run code without any issues.
But if I wanted to compile code in C/C++, suddenly commands such as "gcc" or "g++" are no longer recognized by my command prompt because the PATH variable was overwritten to the java location. I could change it back to the location of my C/C++ compilers, but then my command prompt would no longer recognize the java commands.
How can you make the command prompt recognize all commands? There must be a better way than changing environment variables every time.
You can append all needed paths to your PATH variable. You will want to put them in order of priority, in case there are matches that may potentially be found on multiple path entries.
For example, for Windows:
set PATH=%JAVA_PATH%;%PATH%
set PATH=%CPP_PATH%;%PATH%
...
Or, as a single line:
set PATH=%JAVA_PATH%;%CPP_PATH%;...;%PATH%
(Hypothetical entries - substitute as appropriate.)
Related
What does 'export' do when used in a command line.
For example, and this is only one example, I build a number of C++ libraries and for a library such as zlib-1.2.8 I need to specify the install directories.
To do this I need to do the following in MSYS command line interface. This is just one example
export LIBRARY_PATH="c/libraries/libs;$LIBRARY_PATH"
Would anyone know what the command 'export' actually does in this instance?
Does it permanently install a record for MSYS to user later on when looking for dependencies such as ZLIB . My using make install the zlib library file is placed in this directory.
OR, when I close MSYS is this LIBRARY_PATH lost from MSYS memory?
Thanks
This is the bash syntax to set an environment variable. Using export allows the variable to be seen outside the script in which it's defined.
Environment variables only affect the msys process and any child processes started from that shell. If you want it to persist after you close the command line and start a new one, you will need to put it into a script such as .bashrc
In a makefile, I have the following:
SHELL = $(SOME_DIRECTORY)/sh
showme:
echo $(SHELL)
This is on MS Windows. The situation is that make is in the PATH (or is being directly invoked) but an acceptable shell (i.e. sh.exe) is NOT in the PATH. Neither is it an option to globally modify the PATH variable to include a sh.exe (too much potential conflict between Cygwin, msysgit, and more). Therefore, make defaults to using the Windows cmd.exe command processor, which is hardly ideal.
It is an option to set a system-wide environment variable other than PATH however. So I had the bright idea of putting a path to the directory containing sh.exe in SOME_DIRECTORY and then using it in the SHELL variable in the makefile. But it's not working for some frustrating reason:
make
echo sh.exe
sh.exe
If I use any other variable than SHELL and echo it, then it prints the expected result. But of course that doesn't have the desired effect of changing the shell.
What am I missing here? What do I need to do to have an environment variable with a custom user-specified name (i.e. not SHELL, PATH, etc.) affect the shell used by make?
Which make are you using? GNU make (gmake) 3.82 is most common and it should work in the way you expect. As MadScientist notes, gmake behaves differently under windows wrt SHELL.
You should be able to set SHELL to the full path of an existing executable file, and gmake will use it to execute commands.
However: if SHELL is not set OR if it is set to a non-existent file, gmake will use the value of ComSpec (mind the caps) as the shell.
Is there an exe at the test path you're using? So $(SOME_DIRECTORY)/sh is an existing exe? (Note that you can omit the '.exe' and gmake will supply it for you, but the file must exist)
What we're doing:
We're doing an automated deployment using a tool called Nolio. One of the steps we need to do is to set a few environment variables for applications that are being deployed - for example, JAVA_HOME pointing to our preferred java install directory.
We're using the SET command to permanently set the environment variables - and in most ways, it works great. If I right click on my computer and go into environment variables, they all appear perfectly.
The problem:
Unfortunately, later in the deployment, some command line commands are executed that rely on the environment variables, and the environment variables appear to not be set. Using SET without parameters verifies this by displaying all currently available variables.
Now, if I restart the computer, the command line commands work fine. So, the issue is that while the variables are permanently set and do appear in the GUI, they are not propagated to the command prompts until I reboot.
Another interesting tidbit: If I put the commands in a BAT file and double click it, it runs fine, but if I execute it in the command prompt the variables don't resolve prior to a reboot.
Does anyone know a way around this?
First, what version of Nolio do you use?
The Environment variables to which you set value, in the context of one Nolio action, stay in the scope of this action. (It's like opening two different shells on every action)
The best practice for this case would be using the environment variables arrays inputs in the Nolio 'Run Command Line' action. You should write two arrays of parallel Env variable names and values, and give them as input to the 'Run Command Line' action.
It appears your variables are not in scope for the command prompt. At what point in your deployment process are you using the SET command? Interesting that the GUI recognizes the values, but the command prompt doesn't until you've restarted.
Also, I'm not clear as to why using a .bat file is undesired. I can come up with my own reasons, but what are yours?
EDIT
I've found this article that shows a step that you didn't mention. Have you tried:
rem Set the JAVA_HOME environment variable and insert it into the system path.
rem This will make the javac and java commands reachable from the command line.
set JAVA_HOME="C:\Program Files\Java\jdk1.5.0_14"
set PATH=%JAVA_HOME%\bin;%PATH%
I'm not entirely sure why the command prompt won't recognise commands and the batch files will, but you could use SETX as an alternative to SET to see if that resolves your issues.
I have been trying to setup a environment variable in Cygwin using the command export PRIMOSBASE=/directory/for/primosfiles.
And when i check the variable using the command echo $PRIMOSBASE it shows the /directory/for/primosfiles. hopeful this means the environment variable is set.
But when i try to run a shell script(primos) for the /directory/for/primosfiles, it shows
./primos: line 8: /prilaunch.pl: No such file or directory
chmod: failed to get attributes of `step1.sh': No such file or directory
which means i have not set the PRIMOSBASE environment. could anyone please tell me where i am going wrong...
Thanks ...
Run
echo "export PRIMOSBASE=/directory/for/primosfiles" >> ~/.bashrc
to append the command to the end of your .bashrc file, so that the variable is set each time you use Cygwin. Then run
source ~/.bashrc
to make it take effect immediately.
NOTE: Make sure you use double brackets (>>) to append. It might be a good idea to make a backup of .bashrc just in case. If you're not comfortable with I/O redirection, an alternative is to edit .bashrc with an editor. I think vim is among the default tools in Cygwin.
I had a similar issue trying to get ANDROID_HOME to work in a Cygwin window. When I used the linux path separators, as follows
ANDROID_HOME=/cygdrive/c/Users/User/AppData/Local/Android/sdk my gradlew build script complained it couldn't find the sdk in ANDROID_HOME.
I eventually discovered that I had to set my environment variable in the Windows format, including Windows path separators '\', as follows
ANDROID_HOME=C:\Users\User\AppData\Local\Android\sdk
Note: the PATH and several other environment variables set in Windows are converted into Linux format. I hope this helps others who want/need to use Cygwin + Windows + essentially Windows programs that need environment variables.
I am writing installation in a Makefile in which I need to set the PATH env. variable.
In the windows part of it, I found the following:
set: With set PATH="%PATH%;%CD%" I can change the PATH inside the running environment. There are two problems with this:
The environment is a spawned cmd.exe by make which gets its variable affected and the effect removed as soon as it closes
Even if the previous problem could be solved, still the cmd.exe that calls make would close one day and the modified PATH lost.
setx: A microsoft tool that can permanently change env. variables. According to microsoft itself, this is the only command-line option to do this. Using setx PATH "%PATH%;%CD%" -m however, turns path into the literal %PATH%;%CD% and doesn't replace the variables by their contents!
Note that I am calling make from cmd.exe not cygwin or other modified windows shells that act more like linux. What I'm saying is that, although I can use $(PATH) in my makefile (instead of %PATH%), I can't use pwd (instead of %CD%)
Also note that if in cmd itself I run:
setx PATH "%PATH%;%CD%" -m
it works perfectly. Somehow I need to make make execute this command.
Do you have any idea how to fix this, or what workaround do I have?
P.S. Just for the record, echo "%PATH%;%CD%" in the Makefile also echoes the literal "%PATH%;%CD%" rather than let cmd.exe handle it
Back in the day i Borland C++ Free Command Line tools included a version of make which played well with the dos/windows command line. Probably still floating around somewhere.
Workaround:
Create a .bat file, put the command there, and invoke it from the Makefile.
I still am interested in a direct fix in the Makefile though.