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.
Related
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 that exports a couple of environment variables that are needed for building a software project (Android Keystore Location).
Usually when I call the script the environment variables are exported, and the IDE can access them, so does the export command on the Bash Terminal.
Since I installed Mac OS X El Capitan, the environment variable set by the Bash command
export FOO="bar"
are not returned when I try to access them by
echo $FOO
on the shell. Instead I only get a empty line returned.
If I use printenv from within the shell script $F00 is displayed.
When I call printenv from the Cash terminal $FOO is missing.
I read that the OS X "El Capitan" updates fixes some security issues concerning bash. Could that be the cause ?
You cannot modify or export variables in the shell with a shebang script (a script whose first line begins with #! and the pathname of an executable), if that's what you're doing, because that creates a separate process to execute the script and any variables it exports are only visible to its child processes.
You can only arrange for a script to modify variables in the current shell by executing the script within the current process with . (or source) for example.
For example, the ~/.bashrc, ~/.bash_profile and ~/.bash_logout scripts are executed directly by the shell, so they can set or export variables to be inherited by commands and sub-shells run from the shell.
I am having a similar issue. It seems that environment variables are not being propagated to child processes from bash. I solved it by explicitly adding the variables I need to the child.
export MYVAR=foo
MYVAR=$MYVAR ./executable_to_launch
I would be interested to see if someone has found a better solution.
I am trying to get a bash script to run in git bash while specifying a different .bashrc than the one in my home directory (or none at all) however it is proving an impossible task.
To my understanding this should work:
"C:\Program Files (x86)\Git\bin\sh.exe " --rcfile .bashrc --login -i C:/Scripts/myscript.sh
However no matter what I try either the --rcfile file flag will be completely ignored or the script will get parse errors because it is not parsed by bash.
The following are my findings:
--login flag is needed to get the script to be parsed by bash rather than windows command prompt
--rcfile and also --norc are completely ignored if flags --login is used
I have tried every possible combination I think of, including calling the script within my .bashrc file, swapping the flags around, using the -c flag to run the script command and swapping my .bashrc files around to try using the --norc flag instead.
Is this just a result of shitty bash implementation for windows or am I doing something wrong?
Any help on the matter is appreciated.
You can try sourcing your .bashrc inside the script myscript.sh.
source .bashrc
Or
. .bashrc
As far as I can tell, the -i flag is overridden by the fact that you provide a script for bash to run. Your shell isn't actually interactive, so --rcfile is ignored. The only way I can tell to both run a script and source an additional file is to use a non-interactive login shell; however, in that case, you are restricted to using .bash_profile, .bash_login, or .profile, whichever is found first:
bash --login myscript.sh
There is no --loginfile to override the choice of file sourced prior to myscript.sh.
UPDATE: I forgot about BASH_ENV.
export BASH_ENV=.bashrc
bash myscript.sh
I do not know how you would go about adding BASH_ENV to your environment in Git bash.
I have the following script in ~/bin/ in order to override the default command for gnome-terminal:
#!/usr/bin/env bash
XDG_CONFIG_HOME=~/.config/darkthemesettings /usr/bin/gnome-terminal
I am trying to make the XDG_CONFIG_HOME variable only get seen by gnome-terminal, but in terminal that appears, if I run any other program, the variable is also set in that program. Running echo $XDG_CONFIG_HOME from the terminal gives
/home//.config/darkthemesettings
I understood that if one sets an environment variable without using export, that variable is only available in the script that sets it, not in any child processes. Am I incorrect? How can I achieve what I want here? Thanks
You can use env to unset the variable for the command run inside the terminal, like this:
XDG_CONFIG_HOME=~/.config/darkthemesettings gnome-terminal -x env -u XDG_CONFIG_HOME bash
The assignment XDG_CONFIG_HOME=~/.config/darkthemesettings before the command gnome-terminal sets the variable for the terminal. The terminal will run the arguments after the -x option as shell command. That shell command bash is prefixed by env -u XDG_CONFIG_HOME which unsets the variable in the environment for running bash.
Your understanding is incorrect. Without export they are bash variables. export "promotes" them to environment variables.
You will need to have gnome-terminal run a script that unsets the variables before running the shell.
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