when I at company , I have to export 3 enviroment variables, http_proxy,https_proxy,all_proxy,
I wrote a file ~/bin/setproxy like this
#! /bin/sh
export http_proxy=http://......:8888
export https_proxy=http://......:8888
export all_proxy=http://......:8888
but when I execute this file at bash, then use env | grep http_proxy , I got nothing.
but "source ~/bin/setproxy" works, but is there any way short this to 1 word command.
I wrote another file only 1 line,
source ~/bin/setproxy
but it does not work.
When you execute that script a sub-shell is spawned and the three export are perfomed in that shell, when the script finishes, the sub-shell exits, that's why you don't see the environment variables as set.
You could put that code in a function, say in your .bashrc, and call that, this way it will work, something like the following:
function setproxy {
export http_proxy=http://......:8888
export https_proxy=http://......:8888
export all_proxy=http://......:8888
}
I think your problem is because you are executing either:
~/bin/setproxy
or:
your_other_file_which_sources_setproxy
In both those cases, they run in a subshell which means the export is in that subshell, not the shell you're calling them from.
You can either use the short form of source:
. ~/bin/setproxy
or create an alias:
alias sp='source ~/bin/setproxy'
in your .bashrc or other startup scripts.
That latter solution will allow you to just execute:
sp
to do the work.
Related
How to set a global environment variable in a bash script?
If I do stuff like
#!/bin/bash
FOO=bar
...or
#!/bin/bash
export FOO=bar
...the vars seem to stay in the local context, whereas I'd like to keep using them after the script has finished executing.
Run your script with .
. myscript.sh
This will run the script in the current shell environment.
export governs which variables will be available to new processes, so if you say
FOO=1
export BAR=2
./runScript.sh
then $BAR will be available in the environment of runScript.sh, but $FOO will not.
When you run a shell script, it's done in a sub-shell so it cannot affect the parent shell's environment. You want to source the script by doing:
. ./setfoo.sh
This executes it in the context of the current shell, not as a sub shell.
From the bash man page:
. filename [arguments]
source filename [arguments]
Read and execute commands from filename in the current shell
environment and return the exit status of the last command executed
from filename.
If filename does not contain a slash, file names in PATH are used to
find the directory containing filename.
The file searched for in PATH need not be executable. When bash is not
in POSIX mode, the current directory is searched if no file is found
in PATH.
If the sourcepath option to the shopt builtin command is turned off,
the PATH is not searched.
If any arguments are supplied, they become the positional parameters
when filename is executed.
Otherwise the positional parameters are unchanged. The return status
is the status of the last command exited within the script (0 if no
commands are executed), and false if filename is not found or cannot
be read.
source myscript.sh is also feasible.
Description for linux command source:
source is a Unix command that evaluates the file following the command,
as a list of commands, executed in the current context
#!/bin/bash
export FOO=bar
or
#!/bin/bash
FOO=bar
export FOO
man export:
The shell shall give the export attribute to the variables corresponding to the specified names, which shall cause them to be in the environment of subsequently executed commands. If the name of a variable is followed by = word, then the value of that variable shall be set to word.
A common design is to have your script output a result, and require the cooperation of the caller. Then you can say, for example,
eval "$(yourscript)"
or perhaps less dangerously
cd "$(yourscript)"
This extends to tools in other languages besides shell script.
In your shell script, write the variables to another file like below and source these files in your ~/.bashrc or ~/.zshrc
echo "export FOO=bar" >> environment.sh
In your ~/.bashrc or ~/.zshrc, source it like below:
source Path-to-file/environment.sh
You can then access it globally.
FOO=bar
export FOO
I'm using a bash shell to export some path,like this:
env.sh:
export GOPATH=$GOPATH:$QBOXROOT/pili-zeus
export PATH=$PATH:$QBOXROOT/pili-zeus/bin
after call sh env.sh,I call echo $GOPATH ,but nothing output,and I call export again to check the variables exported,but GOPATH isn't included.But when I copy these commands in the shell file,and execute them directly in command line,it can work!why this happens?I'm using mac.
You need to use source env.sh to get these variables stick to your context (i.e. terminal).
"source is a Unix command that evaluates the file following the command, as a list of commands, executed in the current context."
https://en.wikipedia.org/wiki/Source_(command)
I'm trying to change my environment variables using a shell script, but the shell script isn't changing it.
Sorry for asking that type of question, but I'm learning about Linux, I just can't figure out what I'm doing wrong here..
Here's the script
export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_60
export PATH=$PATH:$JAVA_HOME/bin
export PATH=$PATH:$JAVA_HOME/jre/bin
After I execute this .sh file, when I type
echo $PATH
It doesn't return the new PATH I setted
Instead of executing it like
$ ./script.sh
source it with
$ source script.sh
The first variant creates a new process which does not pass back its modified environment variables to the calling process, while sourcing just executes the script within the already running shell.
See also What is the difference between executing a bash script and sourcing a bash script?
As Andreas explained, you need to source the definition (and you need the export to happen in your current shell process, not in a subshell or child process)
You could instead define in your ~/.bashrc some shell functions to do the job:
## remember the original path at start of the interactive bash
export ORIGINAL_PATH=$PATH
function prepare_for_java() {
export JAVA_HOME=/usr/lib/jvm/jdk1.8.0_60
export PATH=$ORIGINAL_PATH:$JAVA_HOME/bin:$JAVA_HOME/jre/bin
}
function forget_java() {
unset JAVA_HOME
export PATH=$ORIGINALPATH
}
then in your terminal you would type
prepare_for_java
before starting doing Java things, and
forget_java
after you've done with them.
I would suggest to read the Advanced Bash Scripting Guide and Advanced Linux Programming (to get a wider picture).
See also bash(1), credentials(7), fork(2), execve(2), environ(7)
I need to increment an environmental variable by these steps:
envar=1
export envar
sh script_incrementation
echo $envar
where script_incrementation contains something like this:
#! /bin/sh
envar=$[envar+1] #I've tried also other methods of incrementation
export envar
Whatever I do, after exiting the script the variable remains with its initial value 1.
THanks for your time.
A shell script executes in its own shell, so you cannot affect the outer shell unless you source it. See this question for details of that discussion.
Consider the following script, which I will call Foo.sh.
#!/bin/bash
export HELLO=$(($HELLO+1))
Suppose in the outer shell, I define an environmental variable:
export HELLO=1
If I run the script like this, it run inside its own shell and will not affect the parent.
./Foo.sh
However, if I source it, it will just execute the commands in the current shell, and will achieve the desired affect.
. Foo.sh
echo $HELLO # prints 2
Your script can not change the environment of the calling process (shell), it merely inherits it.
So, if you export foo=bar, and then invoke sh (a new process) with your script, the script will see the value of $foo (which is "bar"), and it will be able to change its own copy of it – but that is not going to affect the environment of the parent process (where you exported the variable).
You can simply source your script in the original shell, i.e. run
source increment_script.sh
or
. increment_script.sh
and that will then change the value of the variable.
This is because sourceing a script avoids spawning a new shell (process).
Another trick is to have your script output the changed environment, and then eval that output, for example:
counter=$[counter+1]
echo "counter=$counter"
and then run that as
eval `increment_script.sh`
I (on mac osx) often use
export http_proxy=http://192.168.0.205:1099
to proxy http connection to get a highed download speed. To make things easy， I wrote a shell file named proxy.sh to do this:
#!/bin/sh
export http_proxy=http://192.168.0.205:1099
Before I downlaod, I execute proxy.sh shell command, but I found it did't not come into effect.It lost http_proxy variable in current commnad window(terminal). I must type export command in current terminal,it will come into effect.
So I want to know what's reason for this and a solution? thanks.
Running a shell script "normally" (with proxy.sh for example) results in that running in a sub-process so that it cannot affect the environment of the parent process.
Using . or source will run the shell script in the context of the current shell, so it will be able to affect the environment, using one of the following:
. proxy.sh
source proxy.sh
Another possibility (if you're using bash at least) is to create an alias to do the work for you. You can use something like:
alias faster='export http_proxy=http://192.168.0.205:1099'
so that you can then simply type faster on the command line and it will export that variable (in the context of the current shell).
You could also allow for one-shot settings such as:
alias faster='http_proxy=http://192.168.0.205:1099'
and then use:
faster your_program
which would translate into:
http_proxy=http://192.168.0.205:1099 your_program
That's a bash way to set a variable for just the one invocation of a command.
The export variable will only apply to the script -- if you want it to apply to the shell, you need to use source, and execute the script like so:
. ./proxy.sh
or:
source ./proxy.sh
Note the "." in the first example -- the dot follow by space means the script will apply to the shell.
The reason why your script does not work has been explained by Drakosha & how to make your script work has been explained by Anothony. But with the export in the script you need to source your script each time you open a new terminal. A better solution will be to add the export in .bash_profile or .bashrc
Hope this helps!
When executing a shell script a new shell is launched, the script is executed, and the shell dies. That's why you don't see the variable defined in your shell.
I suggest using an alias for the same purpose.