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:~$
Related
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;"
Putting %appdata% into the run window will open up the Appdata folder, but what is the command to open the User's Documents folder, even when someone else logs in? I thought it was something like %userdir%, but I can not find out what it is. Not sure what to search for in Google either so I am at a loss.
There is no environment variable for this. You'll need to set one. Here's a list of all Windows default environment variables:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds_shelloverview.mspx?mfr=true
*This is for XP, but should be the same for newer versions of Windows
For a single terminal session, you can just use
set USERDOCS=%USERPROFILE%\Documents
For all terminal sessions, you'll need to set a system environment variable. You can do this using the GUI or using setx -m USERDOCS %USERPROFILE\Documents, as described here.
The command to make this happen would be
explorer %USERDOCS%
But if you wanted to make an alias to that (i.e. a openuserdocs command), I can update and explain.
I've set an system environment variable called find which points to a batch script. I did this so that in Win command prompt i could type %find% and it would execute my script. It works the only problem is it only works once, my script takes a parameter or requires user input (have tried both), and then it is as if the %find% is temporarily overwritten, and the %find% of course no longer works, until i reopen the command window. Basically it works once and that's it!
How can i make it work every time? i want to execute my script using the environment variable over and over again at will without reloading the command window.
Thanks.
I created a batch script with the following code:
#ECHO off
echo hello
and added a environmental variable called TEST that points to the script. I have no problem executing the script using the environmental variable multiple times.
Can you please provide some information or code of what your script does?
Remember that find is a MS-supplied utility.
Try using a different name. And show us your batch - even possibly describe what happens when it "no longer works." Games of 20-questions are tedious.
The problem is that the Batch script uses a variable with the same name, so after it run for the first time the variable value is overwritten and no longer works. To prevent this to happen, insert a setlocal command at beginning of the Batch file; this way, when the script ends all variables are reset to the values they had before the script run. This method also delete all new variables defined in the Batch script, so it keep the environment clean.
If your intention is to override the behavior of the existing find.exe utility, you could add the location of the script to the global path variable before your System32 folder (where find.exe is located). For example, let's say your script is C:\Scripts\find.bat. If your path variable is currently set to this:
%SystemRoot%\system32;%SystemRoot%
...then you would change it to this:
C:\Scripts;%SystemRoot%\system32;%SystemRoot%
Beware though... doing this could break other scripts that use the find command (if they don't use the absolute path to find.exe).
If you are just wanting an easy way to run your alternate find command, you could just give it a different name as the others have suggested, then add it to the end of the path or place it in the System32 folder. That would save you from having to type the percent signs at least.
I want to set an alias to my installation of firefox so I can easily start a web page, the problem is that I dont want the script to be system dependent.
Namely I want it to be able to run on a linux distribution where the command to start firefox is already mapped to 'firefox' and can easily be run that way through bash, but on my windows machine I cant seem to get it to assign to the same variable.
I saw that I could set it to '%firefox%' via the set command but that's not quite what I want.
I believe creating aliases is possible on a windows environment because the version of svn that I use auto-installed and was able to assign itself to 'svn'. Anyone know what was involved in them being able to get their alias working, or a similar way to alias a command?
If you include your Firefox path in the %PATH% environment variable, you can start FF with "firefox". Under Windows, you should edit the system-wide settings (see this link).
AFAIK, there is nothing similar to aliases under DOS/Windows (except the %firefox% way you mentioned, too). The 'svn' command you talked about most likely is the same thing, a 'svn.exe' and its path included to %PATH%.
This is a bit restrictive, as you can only use the original filename to launch a program, but you can work around this by creating a batch file in the program's path that launches the program, f.e. a FF.BAT that contains "firefox %1".
Alternatively, you can place a batch file in a path that already is in %PATH%, f.e. the Windows directory. That way, you don't have to modify %PATH%.
I would like to set environmental variables in bash whenever I use a script in the ~/project/bash folder
currently, to run scripts in this folder, I have to run:
cd ~/project/bash
. ./project/bash/env.vars.sh
first, I would like these variables to be automatically set, preferably when either the scripts are used or the user changes to ~/project or therein.
Thanks!
I am not aware of anything that will do something when a script is executed. The closest thing I can see to what you need is to put:
. ./project/bash/env.vars.sh
on the start of each of the scripts.
If that is an option for you, you can create a special user which would have the above line in its ~/.bashrc, so the environment gets set up automatically on login.