This question already has answers here:
Can I export a variable to the environment from a Bash script without sourcing it?
(13 answers)
Closed 3 years ago.
I have created a virtual environment on my debian system and i made a script that activates it (should).
However when i execute the script nothing shows up, not even an error, my guess is that it is running in a different shell or something but I don't know how to solve it.
Here is the code of the script
#!/bin/bash
source ~/PythonEnv/environments/my_env/bin/activate
I have changed the permissions already with chmod u+x, so that is not a problem.
When i execute the script nothing shows up at all. Any thoughts???
Add set -x at the beginning of your bash script will do the trick.
-x Print commands and their arguments as they are executed.
You can see more bash options here
http://linuxcommand.org/lc3_man_pages/seth.html
Adding x-permissions is not necessary, since you are using source with an absolute path. Of course this sets the environment only which is executed by the shell script which you have posted here. If you want the changes in your interactive shell, it is pointless to do it inside a script. You have to source the activate script in your shell (respectively inside that process where you want the environment to be modified).
Related
This question already has answers here:
Setting console env using a shell script
(1 answer)
Defining a variable with or without export
(15 answers)
Closed 9 months ago.
I am working on automating some existing processes through linux shell scripts. What I want to do is run a script remotely through SSH that will then complete a number of tasks on the remote host.
The current file structure is like this:
setup.sh -> exports a list of environment variables
automate.sh -> executes setup.sh then runs automation
Let's say setup.sh does "export VAR=/test" and at the end of the automate.sh script I put the following line "env | grep VAR".
After unsetting VAR and then executing automate.sh, the variable does not get output, meaning it is empty.
Setting the environment variables in .profile or .bashrc will not work for me as setup.sh dynamically sets environment variables based on my parameters (For example, executing code from different regions requires different variables to be set, but all variables have the same name so the same code can be used for all regions).
I am assuming the problem here comes from automation.sh creating a new shell, then setup.sh creating a new child shell, meaning that the exported variables are not available in automation.sh
Can anyone with more experience tell me if this is likely the case? Or how I would verify if this is the case or not? Any suggested solutions would be welcome too.
Thanks.
Update: A suggested solution was to source setup.sh instead of executing it. This solves the problem. However, it would then mean I would need to source setup.sh in multiple places as other scripts will be executed later after automation.sh has complete.
Is there any way to run setup.sh and have the exported variables available to all following scripts?
This question already has answers here:
Global environment variables in a shell script
(7 answers)
Closed 2 years ago.
I have a seemingly simple bash script to setup my environment:
The first two lines are:
#!/bin/bash
export CVE_ENV_DIR=$PWD
easy, hey? Well, see what happens when I run it, I get the following output:
$ echo $PWD
/work/env
$ ./env.sh
$ echo $CVE_ENV_DIR
$
Why does CVE_ENV_DIR not get set to /work/env? What is happening here? When I type export CVE_ENV_DIR=$PWD manually on the shell, it works as expected...
Child shells cannot affect the environment of their parent. If you want the script to affect the parent's environment, you need to:
source ./env.sh
So what's going on? When you run a bash script, either by bash env.sh or env.sh, you're spawning a program with its own environment, an environment that's divorced from its parent. But, when you run the commands contained in the script at the command line, or using source, there is no spawned environment.
Edit to address #syme's comment. Bash scripts meant to be read using source are often pure configuration, containing only assignments and calculations. It's possible to also make them a little more helpful and self-documenting with a clever she-bang hack like:
#!/bin/echo USAGE: source
# Default configuration file for the Frobnicator package.
FOO=bar
BAR=$(stat /baz)
[[ -f /baz ]] && BAZ=file || BAZ=
export FOO BAR BAZ
Making a bash script meant for configuration look like a configuration script, you help future maintainers. You also help yourself my modularizing your script code into distinct parts, each part with its one unique function.
As a side note, please don't export on the same line as you assign.
This question already has answers here:
How to get the default shell
(5 answers)
Closed 6 years ago.
I am composing a bash script to serve as a utility tools.
The challenges I am facing now is:
- user using my tool will be running in bash environment
- however, some of them might default using krcsh or tcsh. they might have aliases or configurations set in there.
So, I need to prompt/guide user to resolve this during installation. My first challenge: How am I suppose to know the user's default shell within my install.sh?
Knowing the "default" shell, I can prompt and guide the user to do necessary transfer to bash.
my testing code:
my result:
1/ is fault obviously. It return the current shell which is my install.sh (bash)
2/ I am doubtful. It seems to be the history of what I have run before. It does not show me my default configured shell. My case, my terminal default shell is bash, and I run tsch for testing purpose. So the script parsed wrong information and will though my default shell is tcsh. It will then assist me to port configurations from tcsh to bash during the installation process.
If you want to check the shell you are using, you can use the following methods:
echo $0 in terminal will show you the program running if you want to check the shell you are currently using.
echo $SHELL - with this command you can read the user's default shell in the terminal you are running.
If you want to prompt, easily you can put the echo $SHELL in the part of your script where you need to show the current shell you are using.
Don't forget to put #!/bin/bash if your script is designed to run in a bash shell!
This question already has answers here:
Why can't I change directories using "cd" in a script?
(33 answers)
Closed 6 years ago.
I am new to bash scripting. This might be obvious to many. please bear with me.
I have a shell script as follows:
#!/bin/bash
echo `pwd`
cd /home/foo/bar
echo `pwd`
Let's say I am currently in dir : /home/foo1
If I execute the above script it prints:
/home/foo1
/home/foo/bar
But once the script completes execution, I have seen that it still remains in dir /home/foo1
I have also seen some scripts where there are explicit commands to reset the working dir using 'cd -' command.
If bash executes all the lines in the script as commands, why does it again reset the working dir?
When you are running an interactive session of bash, and from it, you execute a script (e.g. ./myscript.sh), then bash creates a new bash process to execute the script. Initially, that process get copy of the same environment as the original process (e.g. the current working directory, or environment variables), but if the script modifies the environment somehow, this changes only affect the new process, not the original one. So when the scripts exits, you go back to the original process which retains the original environment. So it is not possible to modify the current directory of the original shell from a script.
As a side note, the following line
echo `pwd`
does not make much sense. You either have to do echo $PWD or simply pwd.
This question already has answers here:
Changing PS1 prompt in a Bash parent shell
(3 answers)
Closed 6 years ago.
I wanted to write a tiny shell script that shortens the commmand prompt when it gets too long. Setting the PS1 variable in bash works fine. When I try the same command directly in a script and run it, nothing happens.
#!/bin/bash
PS1='\u:\W\$ '
I tried eval "PS1='\u:\W\$ '" , export PS1='\u:\W\$ ' and exec PS1='\u:\W\$ ' without any result.
How can I achieve the same result as a direct input in the bash?
Thank you in advance
In general, in UNIX, a process can only change variables for itself and its children -- not its parent ("its parent" being the process that invoked it).
You need to source a script, not execute it, for it to be able to effect your interactive shell's variables. This executes all commands inside the script inside your current shell, not a new shell started as a child process (whose variables' values are thrown away on exit).
# in bash
source yourscript
# or in POSIX sh
. yourscript # mind the space!
In this usage, the shebang does nothing; similarly, the +x permission isn't needed either. It's also typical to name scripts intended to be sourced rather than executed with an extension mapping to the shell they're intended to be used by (yourscript.bash for bash, yourscript.sh for a script which can be sourced by any POSIX shell), whereas scripts intended to be executed rather than sourced should have no extension.