I am trying to set env variable within Chef recipe so that after the recipe is run, I can do echo $VAR1
bash 'set_env_var' do
code <<-EOH
echo export VAR1="https://#{node['fqdn']}" >> /etc/profile
source /etc/profile
EOH
not_if "grep -q VAR1="https://#{node['fqdn']}" >> /etc/profile"
end
Please let me know if there is a better way to do the same.
This is not a feature that Unix supports. The closest you can get is writing to something like /etc/profile.d if your distro's default shell RC files support it but that both won't have any effect on the current shell (you would need to start a new one) and doesn't cover all execution scenarios. Environment variables are probably the wrong answer to whatever you are trying to solve.
Related
This question already has an answer here:
Failed to source ~/.bashrc from bash script
(1 answer)
Closed 6 months ago.
this is my-script.sh content:
#!/bin/bash
set -e
set -o pipefail
echo 'echo "sefo: .bashrc sourced!"' >> ~/.bashrc
echo '=== sourcing .bashrc ...'
source ~/.bashrc
On running:
docker container exec "$container_name" bash /root/my-script.sh
I expect to see on the screen sefo: .bashrc sourced! but I don't get nothing.
What I'm missing here?
You are almost certainly doing it wrong if you are trying to use the interactive features of Bash inside a Docker container. Just put the commands you need to run in the script which needs them, or save them in a file you can source from several scripts inside your image if you have code you need to reuse in them.
The Startup Files section of the Bash reference manual explains how to force interactive behavior, but really, use a noninteractive script instead unless you are specifically trying to affect the interactive behavior of the shell.
The behavior you are observing is probably down to .bashrc containing a snippet near the beginning which forces it to abandon the rest of the file if invoked non-interactively. This is not a built-in feature of Bash itself, but many distributions of Bash ship with an /etc/skel/.bashrc or similar with a stanza like
# If not running interactively, don't do anything
case $- in
*i*) ;;
*) return;;
esac
(This particular example is from Debian.)
This should again convince you that you are doing something wrong if you want to use .bashrc for noninteractive things.
OS: Ubuntu 18.04
I am trying to use my /etc/environment file, to export some variables, to be used by Rails.
cat /etc/environment
....
RAILS_ENV='test'
RAILS_DB_PWD='X35i#98n'
However, when I try:
echo $RAILS_DB_PWD
I get:
X35i
It looks like it's cut off at the #. I would like to include # in the password, and make it available system wide, not just from my local bash shell.
However, if I add this to my .bashrc file, it works fine
Any ideas?
What does shopt show?
echo "${RAILS_DB_PWD}"
Should prevent the shell from interpreting the # that way.
As Elias Soares said in his comment, /etc/environment is not a good place to set a variable with embedded #. Set it in your bash initialization file (for instance /etc/profile) as
RAILS_DB_PWD='X35i#98n'
and it should work. If you intend to span (non-bash) subshells or run programs you are supposed to use this environment variable, don't forget to export it.
I have a strange situation where I'm using zsh full-time, and any bash scripts I run are not picking environment variables properly. Obviously I don't expect bash to pick up env vars that are defined in zsh's environment, so I am using ~/.bashrc and ~/.bash_profile, but that doesn't work either.
For example, here's a test script:
#!/bin/bash
echo $MYTEST
I've added this line to both ~/.bashrc and ~/.bash_profile to cover my bases:
export MYTEST="hello"
I just get a blank line when running the script.
PS: I know running . ./testscript will work, but that's not an option since it's a system-wide script that's failing to pull env vars.
Oops. Maybe I should try having export VAR=val in my ~/.oh-my-zsh/custom/vars.zsh instead of just VAR=val!
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
I'm trying to write (what I thought would be) a simple bash script that will:
run virtualenv to create a new environment at $1
activate the virtual environment
do some more stuff (install django, add django-admin.py to the virtualenv's path, etc.)
Step 1 works quite well, but I can't seem to activate the virtualenv. For those not familiar with virtualenv, it creates an activate file that activates the virtual environment. From the CLI, you run it using source
source $env_name/bin/activate
Where $env_name, obviously, is the name of the dir that the virtual env is installed in.
In my script, after creating the virtual environment, I store the path to the activate script like this:
activate="`pwd`/$ENV_NAME/bin/activate"
But when I call source "$activate", I get this:
/home/clawlor/bin/scripts/djangoenv: 20: source: not found
I know that $activate contains the correct path to the activate script, in fact I even test that a file is there before I call source. But source itself can't seem to find it. I've also tried running all of the steps manually in the CLI, where everything works fine.
In my research I found this script, which is similar to what I want but is also doing a lot of other things that I don't need, like storing all of the virtual environments in a ~/.virtualenv directory (or whatever is in $WORKON_HOME). But it seems to me that he is creating the path to activate, and calling source "$activate" in basically the same way I am.
Here is the script in its entirety:
#!/bin/sh
PYTHON_PATH=~/bin/python-2.6.1/bin/python
if [ $# = 1 ]
then
ENV_NAME="$1"
virtualenv -p $PYTHON_PATH --no-site-packages $ENV_NAME
activate="`pwd`/$ENV_NAME/bin/activate"
if [ ! -f "$activate" ]
then
echo "ERROR: activate not found at $activate"
return 1
fi
source "$activate"
else
echo 'Usage: djangoenv ENV_NAME'
fi
DISCLAIMER: My bash script-fu is pretty weak. I'm fairly comfortable at the CLI, but there may well be some extremely stupid reason this isn't working.
If you're writing a bash script, call it by name:
#!/bin/bash
/bin/sh is not guaranteed to be bash. This caused a ton of broken scripts in Ubuntu some years ago (IIRC).
The source builtin works just fine in bash; but you might as well just use dot like Norman suggested.
In the POSIX standard, which /bin/sh is supposed to respect, the command is . (a single dot), not source. The source command is a csh-ism that has been pulled into bash.
Try
. $env_name/bin/activate
Or if you must have non-POSIX bash-isms in your code, use #!/bin/bash.
In Ubuntu if you execute the script with sh scriptname.sh you get this problem.
Try executing the script with ./scriptname.sh instead.
best to add the full path of the file you intend to source.
eg
source ./.env instead of source .env
or source /var/www/html/site1/.env