I am having a shell script ./my_shellscript.sh, its contents are as follows :
source /path/to/shell_script.sh
Where shell_script.sh contains:
export PATH=/path/to/a/dir:$PATH
which command_name
when I execute the my_shellscript.sh then it shows accurate path to a command, that I executed using "which" command?
When the shell_script.sh terminates and when I again do "which command_name" from command line it doesn't shows any path as it shown when I executed the scripts.
My question is that how to set/persist that path to environment variable [PATH:$PATH] though shell_script.sh terminates?
That's not how environments work, you can't change the parent environment. You can only change your environment, and (optionally) that of child processes to your process.
You could run your ./my_shellscript.sh with source (or .) to export it's variables to your current environment.
source my_shellscript.sh
or
. my_shellscript.sh
Other option to put the PATH variable extension into your .profile file in your home directory. (/home/your_username/.profile) That will be permanent.
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 have a shell script setmyenv.sh as below
#!/bin/sh
export PATH=./abc/tools:$PATH
env | grep PATH
When I run it sh setmyenv.sh, I could see that the PATH env is set accordingly.
PATH=./abc/tools:<whatever my existing PATH setting>
However, after my command finish, if I manually type env | grep PATH on the console, I got
PATH=<whatever my existing PATH setting>
I lost the setting that I set using setmyenv.sh
It looks like the environement is only set in the lifetime of my script run.
How could I have the environment set sticky even after the script ended. i.e. the purpose of the script is to set the environment.?
P/S: I don't want to set it in my .bash_profile nor etc\profile, given I only want to set it when needed, by calling setmyenv.sh, but not every time I open my console. i.e. not per the answer of Using .sh script to set an environment variable or How to set global environment variables using shell script .sh
When you run
sh setmyenv.sh
it runs in a separate sh process and the changes to PATH are lost when the process finishes.
You need to source your script:
source setmyenv.sh
or
. setmyenv.sh
so that it runs in your current shell and all variable assignments are preserved. Remember not to have any exit in setmyenv.sh script. If you do, sourcing the script will terminate your shell.
See also:
Difference between sourcing a script vs executing it
What's a subshell
I have the file script.sh in my-directory folder.
How to run this script with the command `script' from the terminal with no regards to the location I am in the terminal?
You can do so by exporting the path where your script in the PATH environment variable, so that you don't ever have to worry about what your actual script's location is, i.e. if your script is present under say /path/to/dir, do
export PATH=$PATH:/path/to/dir
so that your script's path gets appended to an already existing set if paths under PATH, also remember if you run the above from the command-line, it is not permanent and gets lost soon after the session is terminated. To make it permanent add the same line in .bashrc (or) .bash_profile, depending upon your environment.
Or creating a symbolic link from /usr/bin that is what you intent to do you can do something like ln -s /full/path/to/myscript.sh /usr/bin/myscript and then run as just myscript directly from command line. You can also confirm if is properly added by checking the script's location by which command,
$ which myscript
/usr/bin/myscript
Say your directory is /home/Cristian/my-directory then you can make that part of PATH environment variable like export PATH=$PATH:/home/Cristian/my-directory and then you will be able to call it by typing script.sh and not script. If you want it to be called as script then you should name it script and rename the extension.
The export command will make the directory in question part of PATH temporarily. To make it permanent you may want it to part of .bashrc or other shell rc file if you are in other shells.
I have the following files
build.sh
source exportpath.sh
exportpath.sh
export LD_LIBRARY_PATH=/usr/local/lib/
But,when I am executing this build.sh and then running the echo $LD_LIBRARY_PATH command I am not able to get the LD_LIBRARY_PATH value. How to set this value to the current shell.
I found that we have to source it in the current shell. But I want it done by a shell script.
When I am using source exportpath.sh in current shell, then my LD_LIBRARY_PATH is working but I want this should be done by a shell script.
How can I do this?
There is no magical way to have an environment variable set in the child shell be propagated to the parent shell. See this reply
You could implement some convention, for instance by having exportpath.sh taking a filename, that build.sh would later source (or use eval).
You may want to have your own shell function to wrap both.
But you should usually not do such weird tricks. For example, you could wrap some of your programs into a shell script setting the LD_LIBRARY_PATH (mozilla or firefox is often doing such things).
echo $LD_LIBRARY_PATH
Note the Use of "$" to reference the variable value.
I've seen shell scripts that include a line such as:
source someOtherFile
I know that causes the content of someOtherFile to execute, but what is the significance of source?
Follow-up questions: Can ANY script be sourced, or only certain type of scripts? Are there any side-effects other than environment variables when a script is sourced (as opposed to normally executing it)?
Running the command source on a script executes the script within the context of the current process. This means that environment variables set by the script remain available after it's finished running. This is in contrast to running a script normally, in which case environment variables set within the newly-spawned process will be lost once the script exits.
You can source any runnable shell script. The end effect will be the same as if you had typed the commands in the script into your terminal. For example, if the script changes directories, when it finishes running, your current working directory will have changed.
If you tell the shell, e.g. bash, to read a file and execute the commands in the file, it's called sourcing. The main point is, the current process (shell) does this, not a new child process.
In BASH you can use the source command or simply . to source a file.
source is a Unix command that evaluates the file following the command, as a list of commands, executed in the current context. You can also use . for sourcing the file.
source my-script.sh;
. my-script.sh;
Both commands will have the same effect.
In contrast, passing the script filename to the desired shell will run the script in a subshell, not the current context.