I'm working on a script that automatically installs software. One of the programs to be installed includes its own command line commands and sub-commands when installed.
The goal is to use the program's provided commands to perform an action after its installation.
But running the command right after the program's installation I'm greeted by:
" is not recognized as an internal or external command , operable program or batch file"
If I open a new Powershell or cmd window the command is available in that instance.
What is the easiest way to to grant the script access to the commands?
Bender the Greatest's helpful answer explains the problem and shows you how to modify the $env:PATH variable in-session by manually appending a new directory path.
While that is a pragmatic solution, it requires that you know the specific directory path of the recently installed program.
If you don't - or you just want a generic solution that doesn't require you to hard-code paths - you can refresh the value of $env:PATH (the PATH environment variable) from the registry, via the [Environment]::GetEnvironmentVariable() .NET API method:
$env:PATH = [Environment]::GetEnvironmentVariable('Path', 'Machine'),
[Environment]::GetEnvironmentVariable('Path', 'User') -join ';'
This updates $env:PATH in-session to the same value that future sessions will see.
Note how the machine-level value (list of directories) takes precedence over the user-level one, due to coming first in the composite value.
Note:
If you happen to have made in-session-only $env:PATH modifications before calling the above, these modifications are lost.
If applicable, this includes modifications made by your $PROFILE file.
Hypothetically, other processes could have made additional modifications to the persistent Path variable definitions as well since your session started, which the call above will pick up too (as will future sessions).
This is because the PATH environment variable gets updated, but existing processes don't see that update unless they specifically query the registry for the live value of the update the PATH environment variable, then update PATH within its own process. If you need to continue in the same process, the workaround is to add the installation location to the PATH variable yourself after the program has been installed:
Note: I don't recommend updating the live value from the registry instead of the below in most cases. Other processes can modify that value, not just your own. It can introduce unnecessary risk, whereas appending only what you know should have changed is a more pragmatic approach. In addition, it adds code complexity for a case that often doesn't need to be generalized to that point.
# This will update the PATH variable for the current process
$env:PATH += ";C:\Path\To\New\Program\Folder;"
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'm looking for a way to get the my local path that includes any camel cases that are used in the names. The primary reason is so I can use the same path to make a call in windows wsl. For example, in windows I can call a file as
c:\FoO\bar.txt
c:\Foo\Bar.txt
and windows will display it as c:\foo\bar.txt. When I try to enter the WSL with bash I need to know the actual path since Linux is case sensitive.
I have tried using
$PSScriptRoot
Split-path C:\FoO\Bar.txt
(get-Item c:\Foo\Bar.txt).FullName
but they will only provide the path that to call the script.
How do I get my path as it's displayed in the windows os?
I can't just call the full path of the file I need since I can't guarantee the root directory it starting from. I also don't want to burn up cycles doing a find.
What you want is to look at the Target property you get back from Get-Item. Fullname will come back however you typed it initially, but Target is actually a code property that seems to get the raw path of the object.
(get-Item c:\Foo\Bar.txt).Target
Find the directory with Windows File Explorer and it shows full path name.
Find the directory in WSL or PowerShell and "pwd" or "echo $PWD" gives full path name. Add directory to PATH in $HOME/.profile and you don't need full path name.
I have some automated ways to do it.
See http://ContextKnowledge.blog
"myenv package for Windows 10 + Cygwin + WSL/Ubuntu"
The package includes a few short shell scripts
which find the information and record it in environment variables.
If these shell scripts don't work for you, contact me with more details
and I'll figure out something that will.
I tried to add to the PATH environment variable ";C:\my_EXE" so I can run the programs I put there via cmd (windows 8).
I tried this command:
set PATH=%PATH%;C:\my_EXE
but it changed the PATH environment variable only until the CMD window was closed.
I searched on Google and I found this command:
setx PATH "%PATH%;C:\my_EXE"
that is supposed to set it forever, but it also works only until the CMD window has closed
and it made something like this:
[new PATH]=[old PATH]X2
It appears only in a new cmd and not in system properties(!=cmd, there is the PATH with my new path and not X2)
Why does this happen?
How can I set the PATH environment variable without problems?
There are two persistent PATH variables, the per-machine variable and the per-user one. They get appended together to produce the actual environment variable. (Environment variables in the PATH are also expanded at this point.)
That's why you're getting the path doubled up, because you've set the per-user persistent variable to include everything from the environment variable (which already includes everything from the per-machine persistent one).
You can use setx with the /m parameter to set the per-machine persistent variable, but this isn't ideal:
If the per-user persistent variable is set, its contents will be copied into the per-machine persistent variable, which is likely to be inappropriate;
If the persistent variable references other environment variables, the references will be replaced with the current value of those variables. If the referenced variables change, the PATH will no longer follow those changes. (To be honest, though, most of the time this won't matter: the feature isn't commonly used.)
Instead, consider using pathman which is specifically designed to manipulate paths. You can get pathman.exe from the Windows Server 2003 Resource Kit Tools download.
Note that both setx and pathman may hang if there are any unresponsive GUI applications running, even if the application window is hidden. The best way to minimize this risk is to reboot the machine immediately before running any script that uses setx or pathman.
You should use setx command with "/m" parameter.
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:~$