When installing our software it will create 2 ENV variables. One the path where the software is installed and then the other appending the path variable with this path
MYSOFTWAREROOT C:\Programfiles(x86)\MySoftware\VersionNumber\bin
Path %MYSOFTWAREROOT%
But in very few of our customer machine, instead of %MYSOFTWAREROOT% it is in expanded format like C:\Programfiles(x86)\MySoftware\VersionNumber\bin
We are trying to figure out how this happens? Does any of the windows application does that?
Related
a question regarding messing with Windows Path variable.
My situation is quite specific:
I was trying to install ffmpeg according to this tutorial https://www.geeksforgeeks.org/how-to-install-ffmpeg-on-windows/
The last step was setting the path variable setx /m PATH "C:\ffmpeg\bin;%PATH%"
It worked, however afterwards I noticed that if I try to call python from the command prompt or the powershell if run as administrator, I started getting 'chcp' is not recognized as an internal or external command, (although works fine if run as user), indicating that something is wrong with PATH variables.
I looked into my variables and saw this edit.
Path
It seems to me that the command added the ffmpeg line to the system path and possibly overwritten the original, which is why there are issues when using command prompt as administrator. It probably should have added it to the user Path (not system Path variable)
If that is the case, is there a way to restore the previous system Path variable. Maybe I can paste it from the user Path variable?
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 ?
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.
I was trying to use the pip package
virtualenvwrapper
in Windows through gitbash. The standard virtualenvwrapper-win doesn't work in gitbash and it's useful to not have to switch between consoles so I generally install both.
Normally you simply need to open your .bashrc file in your home directory and type something akin to the following:
export WORKON_HOME=$HOME/Envs/
source Path/To/Python/Scripts/virtualenvwrapper.sh
In this case, however, this produced an error complaining that it reached EOL (end of line) while scanning the string literal. It showed the offending line and it was trying to combine the gitbash $HOME variable (with forward slashes) with the windows environment variable (with the backslashes).
How can I fix it so that it's not combining the environment variables?
The first solution is to manually force the script to find the right path by opening virtualenvwrapper.sh and editing line 126:
"$VIRTUALENVWRAPPER_PYTHON" -c "import os,sys; sys.stdout.write('/path/to/your/envs/folder')"
The underlying cause, however, occurs if you try to set an environment variable in windows for WORKON_HOME. If you simply want to share the Envs folder in your home directory, delete the WORKON_HOME environment variable you created in windows and the issue should go away.
If you want it in a completely different place, then use the absolute path (no environment variables such as %USERPROFILE%) in the windows environment variable and it should work.
I'm trying to use Cygwin to run some astrophysics code called FAST through a program called IDL. In order to do this, I need to set environment variables for the installation path of IDL and the directory of IDL. When I go to the system variables tab in the system settings, I name the variable as appropriate and set the value to C:\Program Files\Exelis\IDL85, but I get an error saying that
STUDENT#SES-6TTJK72 /cygdrive/c/Users/Administrator/Downloads/FAST_v1.0/FAST_v1.0/example_phot
$ ../fast
../fast C:\Program Files\Exelis\IDL85 .:+C:\Program Files\Exelis\IDL85/lib
../fast: line 6: C:\Program: command not found
Now this seems to be happening because Cygwin can't read the space in Program Files as space is used to delimit the arguments, but I've tried every solution I can think of to get around this. I've tried Program\ Files, I've tried quotes around the whole thing, etc. I was just wondering if there was some way to set the windows environment variables in Cygwin itself so I can just type the path out in the notation that Cygwin uses and it would be able to understand it for sure. Any help on this would be much appreciated!