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.
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.
So I need to triage my PATH environment variable and add extra folders so it can find a certain executable. I was wondering is there a way to mimic how the Windows OS walks all the directories in the path to see if it "reaches" an exe?
I know I could write a program but ideally there is a Windows API call.
PathFindOnPath takes in a file name and returns the fully qualified file path, if the file is found. Note, however, that it also looks in standard directories, in addition to PATH.
Is there a way to use the product version number as a variable when building an path for where the exe gets dumped or for other scenarios, etc.
That way I can set the variable once and just have it automatically be updated everywhere.
(eventually, I want to pass in the version number, but thats down the road.)
Thanks
I tried lots of things but there seems to be no way to use a variable product version string (there's a number of threads on the net as well that come to this conclusion). Moreover in our project we also use the version string in the shortcut names, the setup file name etc and found no way to store this in a single place. We found a very manageable solution though via automation. Here's a sample that updates version number and filename using VBScript, but you can also use C# for instance.
Set ISWIProject = CreateObject("IswiAuto19.ISWiProject")
ISWIProject.OpenProject "Our.ism"
ISWIProject.ProductVersion = "4.0.2.0"
ISWIProject.ISWiProductConfigs.Item("Release").SetupFileName = "App_4.0.2.0_Setup"
When building with IsCmdBld.exe you can specify the build location with the -b option. The bummer of this is that it will actually change the ism. It always annoys me that a build will change a source controlled file.
It's also trivial to pass in the product version on the commandline with -y (oddly - this doesn't change the .ism file)
I don't think you can specify a property such as [ProductVersion] in the release location, nor was I able to create a path variable and use that as the release location.
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
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.