I am running a Windows service (I cannot modify) under a given user account. The service does a few things, among them runs a bat script that I should provide.
I discovered that the PATH variable available to the service (as seeen by Sysinternal Process Explorer) is the user PATH environment variable. The default is %USERPROFILE%\AppData\Local\Microsoft\WindowsApps which limits the available command in the script to the built-in cmd commands. I need to have a few more path, as when using cmd where the PATH is the merge of user PATH and system PATH.
Short of changing the user PATH variable and adding part of or all system PATH, is there a way to change user PATH variable that would be seen by the Windows service?
I found a suggestion about editing the registry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\YourService in order to add a PATH environment variable. While it could be the solution I was looking for, unfortunately it did not work. Any suggestion ?
Related
I have been trying to get windows to recognize shortcuts for developer tools. Things like adb for C:\Users\myusername\Andriod\platform-tools\adb.exe. I have tried using CMD and Powershell but they both don't add the PATH I tried the GUI and it doesn't show up.
I've tried setx path "%PATH%;C:\path\to\C:\Users\myusername\Andriod\platform-tools\adb.exe" in powershell and cmd then restarted powershell or cmd
input the variable adb but it pulls a command not recognized error.
Did you try the following?
Adding the path "C:\Users\myusername\Andriod\platform-tools" to your system/user PATH variable? You can do this by start-> environment variable -> environment variable and under system or user, edit the PATH variable and add the above link. Once you do this, restart CMD for it to work.
Add the executable in one of the already existing locations that are in the PATH variable. (Although this is one method, I would not suggest this). Again, if the executable has any dependencies, it must be in a place where the exe itself can access.
Just checked my path ... noticed that C:\windows\system32 was not present.
How can I add this to my path variable, since setx isn't a recognized command? I'm using Windows 8.1 Enterprise if that helps.
PATH=%PATH%;c:\windows\system32
would work at the command line. This will only change it until the command shell exists.
If you go to user accounts and your account I think there is edit environment variables on the left. This will change it for all subsequent sessions.
Consider not changing it permenantly
I have a batch file with below command which I have to share with my team members. In the command below C:\Users\a514502 is part of the directory path and is dynamic depending on user account.
How do I get this and pass it to command below so that my team members do not have to change the path manually in the file?
I understand variables can be used to get to the path and then pass it, but I could not get it working.
-report "C:\Users\a514502\parasoft\Auto_Results" -environmentConfig "C:\Users\a514502\parasoft\prod.env"
Use %USERPROFILE% which references environment variable USERPROFILE containing path to profile directory of currently used user account on Windows, i.e. C:\Users\a514502 in your case.
For a list of environment variables defined by Windows for each user account and including the system variables see the Wikipedia article about Windows Environment Variables.
You should run the command "set|more" to see what environment variables you can work with like these two:
-report "%HOMEDRIVE%%HOMEPATH%\parasoft\Auto_Results" -environmentConfig "%HOMEDRIVE%%HOMEPATH%\parasoft\prod.env"
%USERPROFILE% worked for me and Set|More helped me to understand environment variables. Thanks a lot.
If I add C:\Program Files (x86)\WinMerge to the User PATH variable(by right click on computer -> advanced system settings -> environmental variables), once I open a new cmd shell WinmergeU.exe is not recognized. If I add that path to the System PATH variable, WinmergeU.exe is correctly recognized instead. I though there was no difference between User and System, beside the fact that if I set it on System all the users will see it, while the User PATH is local. Am I doing something wrong?
EDIT 1:
In the follow you can see first the case in which C:\Program Files (x86)\WinMerge is added to the System PATH variable (but not to the User), then when it is added to the User PATH variable (but not to the System). In the first case Winmerge window launch correctly (not shown) and as you can see the path is shown by the echo %PATH% command. In the second case it does not launch and the path it is not shown by echo %PATH%. (note that I clearly confirmed with OK and closed the environmental variable windows before taking these screenshots, and I opened a new cmd right after changing PATH and pressing ok). This issue might be related to my question here (Does echo %PATH% expand to only the system or also the user variables?) but since it might not be I posted two different question.
You must be getting something wrong, or have environmental problems with your machine. Adding a user PATH environment variable does result in it being merged into the environment of a new process.
Update: Perhaps this comment from the MSDN topic on environment variables might be pertinent:
Found out that on Windows Server 2003, once the system PATH passes 1920 characters, the user PATH environment variable is no longer merged with it to set the process PATH environment variable, even though the full system PATH (even if larger) will be included in the process PATH variable.
On Windows 7, also make sure that the system path does not end with a backslash. If it does, the USER PATH is appended to the system path as per usual, but after a line break, which breaks things. In the latter case, the simple command "path" and "echo %PATH% " will print 2 different outputs.
For 16.6, I've confirmed this issue to be a path length issue as well. At a cmd prompt, typing 'set', you can see all of the env. variables. The user path cadence variables and others weren't included. I saved the original complete path text, then I went through and trimmed specific (system) path elements that were deemed unnecessary. after this, in a new cmd session, typing 'set' now shows the user path elements tacked on to the end of the system path elements, because they now fit.
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:~$