This is a real noob question.
When I set up JAVA_HOME using the command line interface I used set JAVA_HOME = C:\Program Files\Java\jdk1.6.0_13
However when I open the JAVA_HOME variable from System>Advanced>Environment Variables the change is not visible. Are these two different settings?
I have this question every time I set up a new Jdk and have never fully understood why the two seem to be different.
The variable you set on command line is for that command shell and any other processes it starts. When you set it from System/Advanced/Environment Variables it affects any other process you start, including command shell, after setting it. Depending on where you set it, it will be available to the same user or any other use who logs in as well.
The JAVA_HOME you set by command line is set only for that session of the shell.
Changes made to a parent process only propagate to newly-created children; try opening a new command prompt and inspecting the value there.
What the others said... :-)
I will add that even after setting the variable in the dialog, processes already running are (in general) not aware of the change: eg. a command prompt window will still display the old value. You have to start another window to see the change.
In some (rare) cases, you might even need to log out and log back to validate the change (I saw that recently again).
Related
So I have written a tool that generates and offline replica of another system. It allows you to run commands typically run online, offline by specify a series of .mgmt and .sock files in the command.
However, I want users to be able to enter these commands as if they were on the live system. Therefore, I had it generate a script that can be sourced to set the environment variables and aliases necessary to allow the user to enter commands easily.
There are a few issues this created that I want to work around, and I am curious is there is a standard best practice when doing this.
I want the bash prompt to change (or atleast be appended to) when the user sources the new variables so it is clear they are running commands on the offline replica. I can do this by setting $PS1. However, I also want a 'deactivate' script to restore the previous user environment. How do I undo this change to the previous one?
When they source my script, env variables change that may have been previously set. I have the script store any previous variables as OLD_<env_variable_name> and create a second deactivate script that restores them as well as removes any aliases (and eventually resets the bash prompt). Is this the best way to do this, or is there a much simpler method I may be missing?
Using eGit to make a commit, the user name is consistently wrong and does not at all reflect what the .gitconfig file in my Win home directory shows (I've also searched for other .gitconfig files, none exist). egit insists on inventing some generated email address that combines my computer name with the domain it is attached - an email address that has only ever existed in egit's own mind.
When performing a commit and push, I have to alter the email each and every time. If I forget, I have to go back and correct it, then do it all over again. Where do I permanently inform egit what the user.email should be instead of the one it wants it to be?
Note: edited user.name to user.email
I'm going to make a wild guess, based on my experience and some of the subtle wording you use here, that your Windows environment does not have the "HOME" environment variable set.
Assuming that's true, what I've discovered is that the eGit algorithm for finding the "home" git config to use doesn't work as well as I'd like. If HOME is set to the Windows HOME, it works fine. If not, it tries some other strategies that don't work for me.
You can verify this in a cmd shell by setting HOME to point to your Windows home, then running Eclipse from that shell, and verify that your git config looks good.
To deal with this, I have written a very small batch program called "runwithhome.cmd" that looks like this:
set HOME=C:\Users\%USERNAME%
start /min %*
This assumes that %USERNAME% is set to your userid.
I use this by changing the shortcut used to start Eclipse, adding the absolute path to this batch file at the beginning.
Note that you'll now have to edit the icon setting, finding the path to the eclipse.exe file.
I came into an environment were when users log into our system, they log in with the csh by default. We also have an automation login (let's call it "autologin") that also invokes the csh by default.
This login in used to execute (via its crontab) all of our scripts (50+) used to send and receive files with our vendors. The results of these individual file transmissions are used to feed a dashboard for each transmission.
The dashboard simply has a light for each file transmission (green light if the last file transmission was successful and red if it failed). This success/fail status is set (in a SQL Server database) from the scripts, using a tsql -H connection.
We are currently using SQL Server 2008, but are upgrading to 2016. So I need to change are 50+ scripts' tsql connection from sql_2008 to sql_2016. I had the idea to use an environment variable (let's say AUTOSQL) that could use.
I could then change all of the 50+ scripts to reference AUTOSQL, instead of sql_2008, and then set the environment variable to sql_2008/sql_2016/and whatever we upgrade to in the future. As I previously mentioned, all users log in with csh as the default shell. The problem I've encountered is all of the shell scripts are written in bash.
How can I set up an environment variable for the bash (our automation) scripts to use, so when we upgrade in the future, I simply have to change the value of one environment variable, instead of changes to 50+ scripts? Thank you
Environment-variables are an operating system feature that is "application agnostic". In Unix-like environments, any kind of program can pass environment variables to any other, that is its child.
The real issue here is that the fifty scripts are run by cron from a crontab file. This means that they will not inherit the AUTOSQL variable, even if it is exported by the csh login script.
See:
Where can I set environment variables that crontab will use?
Also, on the ServerFault StackExchange:
https://serverfault.com/questions/337631/crontab-execution-doesnt-have-the-same-environment-variables-as-executing-user
It's great to see someone simplifying and consolidating their scripts.
If all these scripts are executed in cron (by root), /root is the first place I'd look.
Step 1:
Choice A.) Set and export AUTOSQL in root's .profile
Choice B.) Set and export AUTOSQL in root's .bashrc
Choice C.) Set and export AUTOSQL in root's (whatever you wanna call the file)
export AUTOSQL='sql_{year}'
Step 2:
Make sure you source this file at the top of your scripts. From now on, you can add environment switches at will to this file, since all of your scripts will source it.
. /root/.{bashrc || profile || whatever you decide to name the file}
Hope this helped! Again, the decision is yours.
how can I execute a batch-file or just some (e.g. twice) commands in a job of Hudson (running on windows xp, as a non-service, but may change), that the environment just stays for the whole build.
I need to do this, because I have to change the current path with 'cd' (we are using relative paths in our proj) and 'set' some environment-variables for msbuild.
Thank you in Advance.
Not sure why you need to get out of the service realm. My understanding was so far that Hudson starts a new environment for every job, so that the jobs don't interfere with each other. So if you don't use commands that effect other ennvironments (e.g. subst) you will be fine with adding a "Execute Windows Batch Command".
If your service runs with the wrong permissions, you have two options. First, change the permission of the service (run it under a different user than the local system user) or call the runas command. If for whatever reason you still need to contain changes to certain parts of your job you can always call cmd to create a new environment.
In a .wxs file I have:
<Environment Name="PATH" ... Value="%APPDATA%\Python\Scripts" system="no"/>
Unfortunately this does not seem to work. After installing the installer on another machine, I do see that '%APPDATA%\Python\Scripts' is contained in the PATH environment variable. But typing 'foo' (where foo.exe exists in that set path) prints command not found.
What exactly went wrong here? Is there a way to fix this?
This looks like a bug in Microsoft Windows:
http://support.microsoft.com/kb/329308
Yet, there is no workaround from the WiX side.
I don't think the cmd.exe gets updated unless you recycle them. I've also seen the environment get stuck until logoff. Seems to be more of a Windows behavior than anything else. The Windows Installer does send the message to say the environment was updated... I just haven't seen it work all the time.
If you're updating environment variables and want them available immediately for your applications, then best solution here is to use ScheduleReboot element to prompt the user to restart post-install.
It seems like a bit of overkill just to update an environment variable, but it will do the trick.