I am using Windows 10 and have added 'BRANCH_OUTPUT" user-defined variable using 'Edit environment variables for your account'
I've created a little 'groovy script' from 'Jenkins' and trying to print the 'USER DEFINED VARIABLE". However, script prints 'null' instead of the value
Script
println "PATH=" + System.getenv("PATH")
println "TMP=" + System.getenv("TMP")
println "User Var=" + System.getenv("BRANCH_OUTPUT")
Script Output
Building in workspace C:\Program Files (x86)\Jenkins\workspace\printEnvVar
PATH=C:\Program Files (x86)\Common Files\Oracle\Java\javapath;
TMP=C:\windows\TEMP
User Var=null
Output of 'SET"
C:\Users>set
ALLUSERSPROFILE=C:\ProgramData
BRANCH_OUTPUT=C:\Temp
(1) It prints System-defined variable
(2) It prints user-defined variable which 'already exists'
It does NOT print only 'what I added'. I restarted Jenkins and Windows but nothing worked. User-defined variable is not getting printed
What should I change in Windows (or) am I doing something wrong ?
I guess that you started jenkins and then tried to set the user defined variable in another shell. This does not work because the shell and jenkins are running in different context.
Press the windows-key and search for "environment". You will find a tool with which you can set user environment variables. These variables are available in all contexts, after the context has been restarted. So you need to restart your jenkins afterwards.
Hope this helps
How is the "user defined variable" defined? My guess is you defined it in the Windows environment variables applet, as described in the comments for the previous answer. In your original comment, you mention that it printed the value for a user-defined variable that already exists, but it's not clear what that is. TMP is displayed as C:\Windows\TEMP, and it is uncommon for TMP to be set to that folder for users - even for a system administrator. Only the service accounts get that value. You didn't include TMP in the output of the "set" command, but set typically shows about 50 variables; since only 2 are shown I assume the output was trimmed.
To have user-defined environment variables for your username show up in Jenkins, you would have to run Jenkins as a service using your username. Open the services applet, select Jenkins service and right-click on Properties, go to the Log On tab, choose the 'This account' radio button and enter your username and password.
If Jenkins has already run under the system's Local Service account (even for a moment), there MIGHT be permissions issues because your account certainly does not have the same permissions and Jenkins MIGHT have created files that it can not access under your account. You might have to do a clean install, making sure to change the service configuration before you start Jenkins for the first time. I don't know that this is necessary (I think it is unlikely, unless you have configured security), but I can imagine it is possible.
This is probably not what you want to do for an instance of Jenkins used by others; for that, you would leave Jenkins running as a service under the local system account, and work with your IT/InfoSecurity department to get the variable defined as a system variable as you did working with the people who responded to an earlier answer. If the variable only needs to be known within Jenkins, you could define it globally within Jenkins (will apply to all jobs: go to "Manage Jenkins", "Configure System", scroll to "Global properties", check "Environement Variables" and add "BUILD_OUTPUT" with the value you want to assign to it) or within the job (will only apply to this job: add a parameter in the job configuration, which is passed to the job as an environment variable. If you don't want users to be able to change it when they request a build, the "Hidden Parameter Plugin" - not included in Jenkins by default but very easily added - could be used.)
Your Jenkins Service is running with the System User, but you set the Environment Variable for your Windows User. The easiest solution is to change the Jenkins Service to run with the WIndows Account you set the variable for.
Related
Ahead of time I am a newb at programming/scripting. I mainly research what I want and just edit it to fit my needs when possible.
Environment:
Windows 7
CMD
Usergroup = admin
Occurs when launching as user(admin) or launching cmd as administrator
When I use CMD to change an environment setting, it does not save to the system.
Example:
C:\Users\admin>SET TESTVARIABLE = "This is a test"
C:\Users\admin>SET
TESTVARIABLE = "This is a test"
C:\Users\admin>_
close out cmd, reopen, use SET and the testvariable is no longer there.
Going through System > Advanced System Settings > Environment Variables > System Variables is the only way I can positively make changes to the variables.
This is also affected by any .bat files I make. Mine don't actually get applied when they run but other peoples that I copy(entire .bat file, not just text/context).
This is occuring on my (all at work) desk pc(win10) and 2x Remote Desktop (win7). I am admin and I'm using admin users on these RDP's.
Anyone have any idea what is happening, what i'm missing, how I can research it or fix it?
Variables set using the "set" command are only available in the cmd's instance. To save variables persistently see this: Set a persistent environment variable from cmd.exe
On my Pc, running Windows XP 5.1.2600, following
"My Computer" > "Properties" > "Advanced" > "Environment Variables" > "Path"
I get a string, but in a batch file, or directly typing from prompt, by means of
echo %path%
I get a different one.
Can someone, please, explain what makes them differ and how to fix the issue, setting the "DOS-path" to the same value of "Windows-PATH" ?
Two things:
As others have mentioned, the full value of PATH is the combination of the user's PATH variable and the system's PATH variable.
If you change environment variables (including PATH), any processes already running (including the Command Prompt) will continue using the old environment variable values. You will need to restart those processes to pick up any changes that you've made.
The value of the PATH environment variable you see on the command line (which has nothing to do with "DOS" btw) is the sum of the system wide PATH variable and the user specific PATH variable.
If you open the dialog with the system variables from within the control panel, the upper part contains the user specific environment variables. The lower part contains the system variables.
If you set a PATH variable for your user to e.g. c:\foo, and the system path is be c:\Windows\System32 then you'd see c:\Windows\System32;c:\foo when you do an ECHO %PATH% on the commandline.
Probably the difference you are seeing is that when a new process is made, its default environment contains a PATH variable that is made by merging the system variable with the user variable.
As for how to "fix the issue", there is nothing to fix. The system behaves as designed.
I was getting the same issue where the System Variable that I get through the
"My Computer" > "Properties" > "Advanced" > "Environment Variables" >
"Path"
was different that the one being displayed through the command line interface via
ECHO %PATH%
The fix for this is basically to wait for the change to take place and this can be made faster by restarting the cmd and explorer. To do that you can simply end task for Explorer and CMD and then start a new task or restart it directly.
The same shall be done for the CMD as well.
The Windows registry can hold path entries that do not show up in the Environment Variables version of PATH you see via the control panel. (Why, I do not know).
The difference means that something (likely an install script) made changes to the registry.
To view or change the local user's path variable, look in the HKEY_CURRENT_USER\Environment key.
To view the system path, look in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment
Edit after Mike z reploy
I need to get the string of the path were the Source files are downloaded to the build server from source control. I believe that is called SourcesDirectory.
I've added an invokeprocess activity that calls a powershell script that prints out whatever you pass to the parameter "message". What i need is the name of the variable that holds the binaries directory to pass it to the powershell script (later on i will do more stuff with this variable, of course)
This is how my invokeprocess expression editor looks like:
String.Format(" ""& '{0}' -message '{1}' "" ", "D:\scripts\test.ps1", [placeholder])
All i need is to replace the placeholder with the variable that hold the binaries path (not the drop files) on the build server
Thx!
Thx to mike Z's reploy i was able to know that the variable i was looking for was "SourcesDirectory".
To be able to see this variable i had to add the activity inside the "Run on agent" process.
I was not seeing "SourcesDirectory" because i was adding my "Invoke Process" outside "Run on agent".
I found a way to change the default home directory of a user but I am having trouble with it.
Doing this will change the home drive to C:
But then when I check the environment variable:
It is still H:, with a system restart the Enviroment variables in windows settings will also return to H:/
I have also tried changing it like this:
Which appears to work but if i open a new cmd it will have reverted back to H:/
Now I am trying to do this so that OpenSSH will recognise C as my home directory instead of H: which is a network drive, forcing OpenSSH not to work unless I cam connected to my university network via VPN.
What can I do to set this permanently and in the eyes of OpenSSH?
Nowhere does it mention a dependency between the HOMEDRIVE value and the HOMEDIRECTORY value, what was happening (I think) is that it was failing to map the home directory to the HOMEDRIVE and therefore defaulting back to a safe value (C:)
I wrote a script to update the local AD, replace the values in [] with your values. Copy and paste into a .vbs file and double click on it to run it.
Set objUser = GetObject("WinNT://[COMPUTERNAME]/[USERNAME],user")
objUser.homeDirDrive = "H:"
objUser.HomeDirectory = "[URNPATH]"
objUser.SetInfo
e.g.
Set objUser = GetObject("WinNT://UQBDART-2328/BEN,user")
objUser.homeDirDrive = "H:"
objUser.HomeDirectory = "\\SERVER\SHARE"
objUser.SetInfo
run this, reboot and test. It worked for me.
Sounds like the AD profile on the domain is overwriting the user defined variables. I see your screenshot says you are connected to the eait.org.edu.au domain. That will be the root of your issue. Just to include some details here that I spotted elsewhere, that may be of help to you:
HOMEDRIVE, HOMEPATH & HOMESHARE are set and updated via Active Directory. HOMEDRIVE & HOMEPATH are set even without a home drive set on the account; however they will be overridden by any user account properties set in AD.
Also see these KB articles:
http://support.microsoft.com/kb/841343
http://support.microsoft.com/kb/237566
http://support.microsoft.com/kb/101507
On a side-note for another way around the issue:
-I have in the past created a new instance of the windows command-line shell executable that automatically runs a custom script, so everytime you launch the shell, the environment variable could be overriden.
-To do that you could just put the code you posted to change the environment variable into a batch script, stored wherever you like, then edit the shortcut(s) used to launch the shell by going to properties > then alter the Target box: %SystemRoot%\system32\cmd.exe /K "C:\Documents and Settings\Administrator\My Documents\customshellscript.cmd" (Obviously the part of the path after /K is the location of your custom script)
This way, if you are using openSSH over the console anyway, it will always have the homedrive set correctly.
Changing those environment variable's values is not "supported", at least it will not work as you expect because Windows changes them back.
According to this Microsoft knowledge base article (KB841343), you should use policies, if you need to change these settings. The article also contains links for how to do that (but personally, I never tried). Note that the article was originally written for Windows 2000, but I would strongly suspect, that it is still valid for current Windows versions.
Back in the days of DOS the environment variables were part of the Program Segement which meant that you basically got a local snapshop of the variables limited to the scope of that program.
I'm guessing Windows hasn't changed this and the environment variables available to the CMD window only have the scope of that window and any further windows it spawns. This is supported by this little experiment:
in a CMD window type
set homedrive=h:\
and then test it's updated by typing
set h
from this same window type
start cmd
and in this new window type
set h
when I've done this I get HOMEDRIVE=H:\
if I then just open a new CMD window from the start menu and do the same SET H I get HOMEDRIVE=C:\
I don't know anything about OpenSSH but I suspect like the START CMD got the updated HOMEDRIVE environment variable, if you write a batch to update the environment variable and then execute OpenSSH that'll work.
I had a similar issue, the HOMEDRIVE variable was set to U: which was a drive we no longer used. This was just for one particular user. I went to that user's profile in AD and clicked the Attribute Editor tab. There was an attribute for HOMEDRIVE which I changed from U: to C: - when the user logged in again, it was set correctly. I also updated the HomeDirectory attribute here.
This issue had been really frustrating me trying to find a solution, but I have found what I think is the definitive answer and posted it at:
https://stackoverflow.com/a/60235759/12903197
You need to run 'net user USERNAME /homedir:PATH' where USERNAME is the name of the user you are trying to change and PATH is the drive letter and full path to the desired home folder, which must already exist.
On windows 8:
Hit "windows key".
type "system environment variables".
Allow "Advance system settings" to make changes.
Select "Advance" tab.
Click on "Enviroment Variables...".
Double click on "Path" from "User variable for XXXXXXXX"
Add at the end the variable the new path that you want separated by semicolon.
e.g. C:\Program Files\;C:\Python27\
shareeditdelete (1)flag
I have a Bash script that basically initializes an application and sets parameters. One of these parameters is the location to OpenOffice. Now OpenOffice doesn't set an environment variable when you install it.
What is the best method of finding the location of an application installed and caching that information so you don't have to do the I/O next time?
What I was thinking was simply running a find on /usr/ for the OpenOffice directory which has a specific file. When it's found store that directory in a environment variable and in this script check if the environment variable is set and is a directory, if so use it, if not search again.
This would allow the script to work without user interaction but also allow the user to set a path themselves (since it's an environment variable).
This seems like a "bad practice", so I'm hoping maybe someone else can give me the common way of getting information about a software install. If it helps, OpenOffice will most likely be installed using aptitude.
The way I've usually seen it done is with some code like this:
[ -z "$OO_EXE" ] && OO_EXE=/usr/bin/oo # or whatever the executable is called
Then you can always assume that the OO_EXE environment variable is set later on in the script. The user can override the default by setting OO_EXE in the environment before running the script, but if he doesn't then the script falls back to the default.
If you want to dynamically find the default the first time the script is run and reuse it every other time, then I would prompt the user for the path the first time the script is run, drop a dot file in the user's home directory, and read from that file every other time.
Many applications set such values when they install themselves. For example, when a user runs the configure script for your app, the user has the ability to specify the location of ooffice. The script will use that value or try to find it or use a default if the user leaves it unspecified. When the app is installed, it will have a hard-coded value.
You could use the command which.
asafe#mimimi:~$ which openoffice.org
/usr/bin/openoffice.org
asafe#mimimi:~$