I want to run a script /usr/sbin/run.sh when I start my container on Jelastic, so I did following:
Set Environment Variable, PATH = /usr/sbin
In RUN command section, I set it to run.sh
Then I follow normal procedure to add container on Jelastic, but it gave following error(everything will be fine if I don't set environment variable and RUN command):
{
"result":99,
"source":"JEL",
"error":"java.lang.NullPointerException",
"params":{
"extip":"false",
"session":"114x1d38909aa5d9848b418276a6ca653875",
"actionkey":"changetopology;dbde54d07b423f0a770cf08727f19272;licds30",
"fixedCloudlets":"1",
"ismaster":"false",
"flexibleCloudlets":"16",
"appid":"dbde54d07b423f0a770cf08727f19272",
"nodeType":"docker",
"displayName":"licds30/baoqi:v3",
"metadata":{
"dockerHubUser":"sdfs23fs",
"dockerName":"licds30/baoqi",
"dockerRunArgs":"run.sh",
"dockerHubUrl":"https://index.docker.io/",
"dockerEnvVars":{
"PATH":"/usr/sbin"
},
"layer":"cp",
"dockerTag":"v3",
"dockerHubPassword":"xxs23saddjd"
}
},
"methodName":"addNode(docker)"
}
Can anyone advise how to resolve the issue?
Many thanks!
J.
As I know environment variables are a set of dynamic named values that can affect the way running processes will behave on a computer.
https://en.wikipedia.org/wiki/Environment_variable
In Jelastic Docker's environment variables are designed for specifying of the destination directory/application paths and for the specifying of the specific/needed information about ports, hosts, enabled/disabled features.
In your case the correct scenario is to Set Environment Variable HOME = /usr/sbin, since the default location of the HOME directory is /root.
Environment Variable PATH contains a colon-separated list of directories that the shell searches for commands that do not contain a slash in their name (commands with slashes are interpreted as file names to execute, and the shell attempts to execute the files directly) in other words it is determines location of the main system components. (For example: when you are executing command ping system is actually runs binary of the program that is located at /bin/ping)
Related
what it might worng in this code its not taking ipconfig command, does it is because of path settings in environment variable
The environment variable path contains a semicolon-separated list of directories which cmd scans to find an executable.
You should not change path without understanding the consequences. The file ipconfig.exe is usually stored in c:\Windows\System32 and possibly also c:\Windows\SysWOW64. At least one of these directories should be included in the list assigned to path in order to execute the command.
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
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 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.
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:~$