We have few executable which need some environment setting.
We manually running those scripts before running the executable
Like
$ . setenv.ksh
We have to encompass call these in one script to avoid the manual work.
We written a sh script like
#!/bin/sh
. setenv.ksh
./abc &
Still the environments are not setting in that session. I think the “. setenv.ksh” runs with fork and it’s not setting the environment.
Please me to solve this problem. Which command we use to run the setenv.ksh so, this will work fine.
Thanks
I notice the environment script is called setenv.ksh but you try to run it from /bin/sh. Maybe your system has a shell other than ksh as /bin/sh and it misparses something it setenv.ksh. Try changing the shebang line to #!/bin/ksh (or whatever the path to ksh is on your system).
In setenv.ksh, you need to export all environment variables you set so that any sub-shell will inherit the values:
export MYENV=myValue
Related
I have a bash script where I am trying to use values of some environment variables. Those variables are defined - I see the keys and values if I run printenv.
Also, these variables are defined and exported like
export FOO="bar"
in both ~/.bash_profile and ~/.bashrc.
I am trying to execute the script via ./script-name which fails to get the environment variables. If I run sudo -E ./script-name, that somehow gets the script the variables it needs.
Confused as to why these variables aren't available to the script even when they are exported in above files.
The only thing I can think of, is that for some reason, the shell process which you are calling to run the script, does not have full read access to your current environment.
ls -al /usr/bin/bash
ls -al /bin/sh
Assuming neither of them are symlinks, make sure that your current user has read and execute priveleges. A safer (in security terms) option, would be for you to install bash in ~/opt, and use #!~/opt/bin/bash as your shebang line.
I've searched for an answer and read about different ways to do that in Mac but some of them are not relevant for Mojave or just didn't work for me.
I need to set Environment variable in terminal (bash), run script that creates processes, and I would like those processes to know the value of those environment variables.
How can I do that?
btw - writing export ENV_NAME=ENV_VAL in .bashrc or in .bash_profile didn't work.
Works for me. Have you RTFM? For example, ~/.bashrc is only read by interactive shells, not shell scripts. And ~/.bash_profile is only read by login shells. Again, shell scripts don't usually use the -l flag that would make them login shells. Also, if you put an export VAR=value statement in your ~/.bashrc it won't affect your current interactive shell. You need to start a new shell; e.g., by typing exec bash. Once you do that you should find the env var is defined. And it will be inherited by any process, including a shell script, you launch from that interactive session.
Note that if you run your script via crontab, for example, then you'll need a different means of setting the env var. For example, by using the --init-file flag or the BASH_ENV env var.
I have a shell script written in eclipse
#!/bin/sh
#
# 07/28/2006. .sh file for the Hpims Cron job.
# Runs daily.
. /db2/db2inst1/sqllib/db2profile
APPHOME=/devl/prod/vehmgr/cronjob/HpimsCron
JAVA_HOME=/usr/java14
JAVA_EXEC=$JAVA_HOME/bin/java
JAVAC=$JAVA_HOME/bin/javac
#export APPHOME JAVA_HOME JAVA_EXEC JAVAC
export JAVA_HOME JAVA_EXEC JAVAC
cd $APPHOME
CLASSPATH=$JAVA_HOME/jre/lib/rt.jar:$JAVA_HOME/jre/lib/i18n.jar:/appl/jConnect/classes
/jconn2.jar:/appl/net/jserv-1.1.2/libexec/jndi.jar
CLASSPATH=$CLASSPATH:/appl/net/jserv-1.1.2/libexec/mail.jar:/appl/net/jserv-1.1.2/libexec/mailapi.jar:/appl/net/jserv-1.1.2/libexec/activation.jar
CLASSPATH=$CLASSPATH:/appl/net/jserv-1.1.2/libexec/smtp.jar:/appl/net/jserv-1.1.2/libexec/soap.jar:/appl/net/jserv-1.1.2/libexec/ldap.jar
CLASSPATH=$CLASSPATH:/home/db2inst1/sqllib/function:/home/db2inst1/sqllib/java/db2java.zip
CLASSPATH=$CLASSPATH:.
CLASSPATH=$CLASSPATH:/devl/prod/vehmgr/cronjob/HpimsCron
export CLASSPATH
#cd $APPHOME
#$JAVAC HpimsCron.java
$JAVA_EXEC HpimsCron
Question is - how to execute this shell script on Windows XP. I have made changes to the HpimsCron.java file and now I need to run this shell script manually to see the changes reflected.
In general I'd do the following:
CLASSPATH=something
CLASSPATH=$CLASSPATH:something/else
export CLASSPATH
Becomes
set CLASSPATH=something
set CLASSPATH=%CLASSPATH%;something\else
(note, the ; instead of : and \ instead of /)
EDIT:
The call to dbprofile suggests another script that may not be portable and whether the app (HpimsCron) would work on Windows is also highly dubious.
Cygwin will allow you to run shell commands on Windows. This post How do you run a crontab in Cygwin on Windows? also explains how to get cron working on Windows under Cygwin.
This won't run under Windows, it's Unix shell specific
You might give Cygwin a try. It offers a Unix-like environment on a Windows system.
I need to set some environment variables in Ubuntu. I do the following and it works:
export PATH="/home/vagrant/ns-allinone-2.35/bin:/home/vagrant/ns-allinone-2.35/tcl8.5.10/unix:/home/vagrant/ns-allinone-2.35/tk8.5.10/unix:$PATH"
export LD_LIBRARY_PATH="/home/vagrant/ns-allinone-2.35/otcl-1.14:/home/vagrant/ns-allinone-2.35/lib"
export TCL_LIBRARY="/home/vagrant/ns-allinone-2.35/tcl8.5.10/library"
But I move the same thing in a script envexport.sh and execute it, the environment variables are not getting set.
Where am I going wrong? How to accomplish this?
Thanks.
If you just run the script, the environment variables get destroyed when the script finishes.
Use . envexport.sh. That way the commands get executed in the current shell (environment).
When you run a command in the shell, the shell creates a subprocess (child process). All the environment variables which were defined or changed down in the subprocess will be lost to the parent process.
However if you source a script, you force the script to run in the current process. That means environment variables in the script you ran will not be lost.
One thing that may help is if you will want those variables set for all of your sessions you can place the same commands in your .bashrc file by running the following command and pasting the lines in the file.
vim ~/.bashrc
and the run
source ~/.bashrc
in any terminals you currently are running. If you start any new terminals they will automatically have your directories added to your path.
I tried activating a VirtualEnv through a shell script like the one below but it doesn't seem to work,
#!/bin/sh
source ~/.virtualenvs/pinax-env/bin/activate
I get the following error
$ sh virtualenv_activate.sh
virtualenv_activate.sh: 2: source: not found
but if I enter the same command on terminal it seems to work
$ source ~/.virtualenvs/pinax-env/bin/activate
(pinax-env)gautam#Aspirebuntu:$
So I changed the shell script to
#!/bin/bash
source ~/.virtualenvs/pinax-env/bin/activate
as suggested and used
$ bash virtualenv_activate.sh
gautam#Aspirebuntu:$
to run the script .
That doesn't throw an error but neither does that activate the virtual env
So any suggestion on how to solve this problem ?
PS : I am using Ubuntu 11.04
TLDR
Must run the .sh script with source instead of the script solely
source your-script.sh
and not
your-script.sh
Details
sh is not the same as bash (although some systems simply link sh to bash, so running sh actually runs bash). You can think of sh as a watered down version of bash. One thing that bash has that sh does not is the "source" command. This is why you're getting that error... source runs fine in your bash shell. But when you start your script using sh, you run the script in an shell in a subprocess. Since that script is running in sh, "source" is not found.
The solution is to run the script in bash instead. Change the first line to...
#!/bin/bash
Then run with...
./virtualenv_activate.sh
...or...
/bin/bash virtualenv_activate.sh
Edit:
If you want the activation of the virtualenv to change the shell that you call the script from, you need to use the "source" or "dot operator". This ensures that the script is run in the current shell (and therefore changes the current environment)...
source virtualenv_activate.sh
...or...
. virtualenv_activate.sh
As a side note, this is why virtualenv always says you need to use "source" to run it's activate script.
source is an builtin shell command in bash, and is not available in sh. If i remember correctly then virtual env does a lot of path and environment variables manipulation. Even running it as bash virtualenv_blah.sh wont work since this will simply create the environment inside the sub-shell.
Try . virtualenv_activate.sh or source virtualenv_activate.sh this basically gets the script to run in your current environment and all the environment variables modified by virtualenv's activate will be available.
HTH.
Edit: Here is a link that might help - http://ss64.com/bash/period.html
On Mac OS X your proposals seems not working.
I have done it this way. I'am not very happy with solution, but share it anyway here and hope, that maybe somebody will suggest the better one:
In activate.sh I have
echo 'source /Users/andi/.virtualenvs/data_science/bin/activate'
I give execution permissions by: chmod +x activate.sh
And I execute this way:
`./activate.sh`
Notice that there are paranthesis in form of ASCII code 96 = ` ( Grave accent )
For me best way work as below.
Create start-my-py-software.sh and pest below code
#!/bin/bash
source "/home/snippetbucket.com/source/AIML-Server-CloudPlatform/bin/activate"
python --version
python /home/snippetbucket.com/source/AIML-Server-CloudPlatform/main.py
Give file permission to run like below.
chmod +x start-my-py-software.sh
Now run like below
.start-my-py-software.sh
and that's it, start my python based server or any other code.
ubuntu #18.0
In my case, Ubuntu 16.04, the methods above didn't worked well or it needs much works.
I just made a link of 'activate' script file and copy it to home folder(or $PATH accessible folder) and renamed it simple one like 'actai'.
Then in a terminal, just call 'source actai'. It worked!