Hi what is the main need for setting an Environment Variable, while we have been installing many languages. What's there need? And does the installation cant set(in case of java)? Why so?
Environment variables are set to allow access to command line tools and to enable other tools to interact with SDKs more easily. For example, with Java on Windows, if the environment variable is not set on the PATH, running javac is much more cumbersome because you need to type in the full path to the command each time:
C:> \jdk<version>\bin\javac MyClass.java
In Java setting the environment variables isn't required; it's just easier. Other languages may be more stringent, though I haven't seen any specific examples I could cite. You can read the article How Do I Set the Path System variable? for specifics on how to do this.
The Java installer doesn't change the path variable, but other tools do (Microsoft's own, for example). I assume it's a design decision on the part of Sun/Oracle rather than any particular technical limitation.
In case of JAVA You can run the JDK just fine without setting the PATH variable, or you can optionally set it as a convenience. However, you should set the path variable if you want to be able to run the executables (javac, java, javadoc, and so on) from any directory without having to type the full path of the command. If you do not set the PATH variable, you need to specify the full path to the executable every time you run it.
windows make the Environment variable because of access and organize promotions to users and protection
hope this will h e l p you
Related
I need to setup these two paths in my bash_profile
export AIRFLOW_HOME=pwd/airflow
and
export AIRFLOW_HOME=pwd/airflow_2
for the same server so that two different versions of airflow can coexist. Is this possible?
Can't think of any solution.. any suggestions will of great help.
Every environment variable must, by definition, be unique and non-ambiguous.
Either the software itself, or the script wrapping the software, could work with another environment variable (i.e. AIRFLOW_HOME_OPTS) which could be assigned the following value
AIRFLOW_HOME_OPTS="pwd/airflow:pwd/airflow_2"
which the wrapper could then parse depending on command line options, i.e. --default/--v2 .
Assuming this is an installation dedicated to a single user, you could also have the libraries installed in each of
pwd/airflow_1
pwd/airflow_2
and, again via wrapper option, create a symlink on the fly to whichever is the one you wish to use at the time the command executes, and removes that when the program ends.
Is it possible to change any MPI settings during runtime? The only similar thing I know about is manipulation with intra and inter-communicators (docs).
Do you know about some other things? I'm thinking about changing PATH, MPIEXEC_TIMEOUT, prefix of PATH etc.
I need it just for demonstration purposes for one project, so anything that can be set during runtime, is enough :-)
The now standard way of doing this is with control variables (CVARs). These are all implementation specific, so you'll have to look in the documentation for your particular library. Often, these can be set with an environment variable.
For example, in MPICH 3.2, there is an environment variable called MPIR_CVAR_ASYNC_PROGRESS that allows you to turn on and off asynchronous progress at runtime. These things are documented in the tarball in a file called README.envvar.
These things will not be consistent between implementations so you'll have to be careful about names depending on where you are running. For instance, in Open MPI, I'd imagine that most of these environment variables will be prefixed with something like OMPI_something since that's more in line with the naming scheme used by that project.
C:\Users\redacted\Documents\redacted>gfortran hibrac.f -o hibrac.exe
'gfortran' is not recognized as an internal or external command,
operable program or batch file.
https://gcc.gnu.org/wiki/GFortranBinariesWindows seems similar to my problem: gfortran.exe is in C:\Windows\MinGW\bin -- except the solution appears not to apply to Windows 8.1 Pro:
Right click on My Computer, Properties, Advanced Tab, Environment Variables.
Instead I tried: Right click on 'This PC' within File Explorer, Properties, Advanced system settings, Advanced Tab -- and I cannot find an equivalent-looking section that allows me to proceed with the advised solution.
As background information:
I had installed MinGW Installation Manager which installed mingw32-gcc-fortran (together with mingw32-base, -gcc-g++, and -gcc-objc) in the recommended C:\Windows\MinGW folder, without any apparent error message.
Isn't it acceptable -- standard practice -- to have one's code in a folder separate from this MinGW folder? i.e. a subdirectory of my Users\account rather than a subdirectory of MinGW. This isn't the problem, is it? What do I need to do to get it to recognize the gfortran.exe, or call it correctly?
Please tell me what to do to get it working. If it's relevant, I have a Japanese computer with an English language pack installed (it seems to have some gaps, such as some text in the Settings charm or startup/shutdown text being in Japanese).
This looks very much like you have neglected to add C:\MinGW\bin to the effective PATH for the command window, in which you are attempting to run the gfortran command.
Your question isn't entirely specific on this point, (i.e. you could improve the question), but you hint that you were unable to add the appropriate PATH entry to the global environment variables, because you couldn't find the appropriate control panel applet? I know that this is often recommended as part of a MinGW setup, but the installer will not do it for you, because I, as the maintainer of mingw-get, don't consider that to be best practice; much better, IMO, to add it for each specific command window in which you need it to take effect, by running (once, at the start of each command prompt session) the command:
path %PATH%;C:\MinGW\bin
If you prefer, you may create a batch file to do this for you, along with any other initializations you wish to perform, (or better still, use MSYS as the working shell environment, in which case the PATH initialization is taken care of by the shell's own initialization scripts).
I already have a variable named PATH set for my .net 4 framework. I want to set up a variable for JAVA but when i use a variable-name other than PATH it doesn't get Java working and if i change default .net variable name PATH to something else .net framework gives problem.
Whats' the solution?
Regards,
Sanket
(From comment above)
You could always set the variables inside a launch script. I'm confused why you need different PATH values for running .NET and Java though. Your PATH usually tells the OS where to look for executables to run. If that's really what you're changing, then you should just take the union of the two. On Windows you just separate each path in the PATH with a semicolon.
If I have a System and User environment variable with the same name, how are they processed? Are they concatenated? Does the user variable override the system variable? Taking that into account, if I need to add something to the Path variable, where is it more convenient to add it?
I think this article should answer you question: Environment variables in Windows NT
User environment variables
User environment variables can be
viewed from Control Panel as well. The
user may add, delete or modify the
environment variables in the User
Environment Variables for User field.
These variables take precedence over
system environment variables. The user
path is appended to the system path.
Everything splash says in their answer is correct. To be absolutely clear, there is a difference between how the user path environment variable is evaluated, and the other user environment variables are evaluated. A regular user environment variable overrides completely a system one with the same name if both exist, but only for the specific user it is specified for. However, the user path variables is treated differently. It is appended to the system path variable when evaluating, rather than completely replacing it. I believe splash states that, but they do it so concisely I think it needs spelling out.
Everything that splash and Simon say in their answers are correct. The idea that the user path variable is appended has been highlighted, and I believe the consequences of that difference require some additional treatment.
Path = %Path% (System) ; %Path% (User)
When you execute an executable program (or any executable script, such as .bat, .vbs, etc.) you do not need to provide the fully qualified path.
For instance, to run java, you can type in any of these:
C:/Program Files (x86)/Java/jre6/bin/java -version
java.exe -version
java -version
The first example uses a fully qualified path. This will always use the version of the Java at that exact path.
The second example will go through each of the directories in the %Path% environment variable, looking for an executable file named java.exe. It will run the very first one that is found, and stop searching. If there are two files named java.exe somewhere on the %Path%, only the first one found is used.
The third example, like the second, will iterate over the directories listed in the %Path%. In addition, because a file extension was not provided, a list of executable file extensions are appended to the name of the file, in the order specified in the %PATHEXT% environment variable. If there are several files named java.com, java.exe, java.bat, etc. somewhere on the %Path%, only the first one found is used.
You can see the list of executable path extensions on your system by creating the following batch file:
#echo off
echo %PATHEXT%
pause
On my machine, these are:
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.PY
What does all this mean?
In stark contrast to other environment variable, the user path does not allow you to override the system path. The exact opposite is the case. From the examples above, there are many cases where you may with to change the default version of Java. However, if there is already a Java version listed in the system path, that is the version that will ALWAYS be found first, because the path is searched in order, from left-to-right, and the user path is appended on the right-hand side, with the system path on the left.
What can I do about it?
If you do not have access to system environment variables, you cannot override default programs on the system path by using the user path. (In fact, it must be this way, or certain programs would stop working correctly, and would open your system to tampering by malicious software. Nobody wants that.)
Instead, you must use a fully qualified path if you must use a specific version.