I would like to know what does the command source do. I have tried:
whatis
$ whatis source
source: nothing appropriate.
man
$ man source
No manual entry for source
source (-h, --help, etc...)
$ source
source: not enough arguments
But it seems no documentation about it.
I commonly use it to save any changed on my dotfiles, but what does it exactly do? Why there is not documentation about it?
source is a bash shell built-in command that executes the content of the file passed as an argument, in the current shell. It has a synonym in . (period).
Syntax
. filename [arguments]
source filename [arguments]
From the source manual
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 short
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.
Be careful! ./ and source are not quite the same.
./script runs the script as an executable file, launching a new shell to run it
source script reads and executes commands from filename in the current shell environment
Note: ./script is not . script, but . script == source script
Is there any difference between source in bash after all?
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've encountered the following command:
source foo -c configs/foo.config
What is -c flag is actually may do here? foo is bash script, foo.config also looks like one.
The source command is a bash-specific alias for the POSIX-standardized command .. The specific usage you're asking about is mentioned by POSIX as an allowable extension:
The KornShell version of dot takes optional arguments that are set to the positional parameters. This is a valid extension that allows a dot script to behave identically to a function.
Thus, when code read from foo is invoked, its $1 will be -c and its $2 will be configs/foo.config.
This is also explicitly documented if you run help source in bash:
source: source filename [arguments]
Execute commands from a file in the current shell.
Read and execute commands from FILENAME in the current shell. The
entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.
Exit Status:
Returns the status of the last command executed in FILENAME; fails if
FILENAME cannot be read.
Note the text above: If any ARGUMENTS are supplied, they become the positional parameters when FILENAME is executed.
I was following a tutorial on openvpn and it needed to execute a command . ./vars. It displays a message. On reading the file I found that it executes a echo command in file and disregards everything else in file. On adding other echo statement, it also gets executed. So i would like some basic explanation on this. Is this something related to bash only?
. and source are synonymous: it just runs the file line-by-line in the current shell. ./vars is just a path to some file named vars in the current directory. So all that command does is run the file vars line-by-line.
As for the rest of your question, I don't really understand what you're asking. Can you clarify?
The . at the start has an explanation here, and the ./filename is a relative reference to the file.
. sources or imports a bash script to the current script you are working on ( if you are creating a script ) or to the current tty ( terminal or command line ) if you are working with the commandline interface. The script it is sourcing must be an executable ( it should have the -x flag set )
./filename means find filename in the present directory am in. if you execute only ./filename in tty ( terminal or command line ) or inside a script, it finds filename and check if filename is executable, then it runs filename . You should take not that ./ means the present working directory. Using two dots ( ../filename ) instead of one with filename tells the bash parser go to the previous directory before the present one am in
using . ./filename you are telling the bash parser to import or source (.) filename (./filename ) in the directory you are currently on
This is not a problem affecting me in any way, but just for curiosity...
I have added export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
to my ~/.profile to include a new directory into my bash search.
Then, I ran $ source ~/.profile to reload may shell and I checked my path using $ echo $PATH
The question is:
- why every time I ran source ~/.profile, it appends the same information again,
- how can I clear it?
What I have tried:
- Tried running it multiple times and it keeps adding the same
- Tried to figure out what does the source command does but could not find where it is which source
First question:
why every time I ran source ~/.profile, it appends the same
information again
Simply, source <FILE> does not reload your shell. It only
executes all commands saved in <FILE> as if they were typed directly
by you in the terminal.
Second question:
how can I clear it?
To reload shell open a new terminal
window/tab. Doing just bash or exec bash won't work because a new
process will inherit its parent environment.
Third question:
Tried to figure out what does the source command does but could not
find where it is which source
As I explained once here https://unix.stackexchange.com/a/202326/72304:
All commands that can be run in Bash without typing an explicit path
to it such as ./command can be divided into two parts: Bash shell
builtins and external commands. Bash shell builtins come installed
with Bash and are part of it while external commands are not part of
Bash. This is important because Bash shell builtins are documented
inside man bash and their documentation can be also invoked with help
command while external commands are usually documented in their own
manpages or take some king of -h, --help flag. To check whether a
command is a Bash shell builtin or an external command:
$ type local
local is a shell builtin
It will display how command would be interpreted if used as a command
name (from help type). Here we can see that local is a shell builtin.
Let's see another example:
$ type vim
vim is /usr/bin/vim
In your case:
$ type source
source is a shell builtin
Now we know it's not an external command but a shell bultin (this is why which does not find it) so we need to use help to see what it does:
$ help source
source: source filename [arguments]
Execute commands from a file in the current shell.
Read and execute commands from FILENAME in the current shell. The
entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.
Exit Status:
Returns the status of the last command executed in FILENAME; fails if
FILENAME cannot be read.
source executes the content of the file passed as argument in the current shell.
It appends the same information again because export is appending a string to PATH, without checking anything (it is not checking if the substring that you want to append is already in the variable).
To avoid appending to PATH every time, you should save the values of your PATH without referring to itself, e.g.:
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/local/go/bin:$GOPATH/bin
Edit:
To check if the directory is already in PATH:
if [[ ":$PATH:" != *":/usr/local/go/bin:$GOPATH/bin:"* ]]; then
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
fi
Here I have one script which exporting some necessary path in Linux. After running this script I have to run some other scripts.
I have two scripts
1 import.sh = importing paths
2 main.sh = this script do something with HCI (use for Bluetooth purpose).
when I run ./import.sh and than ./main.sh then it's giving error.
And when I run . ./import.sh and then ./main.sh then it's working fine.
So what is the diff between ./import.sh and . ./import.sh?
What happens if I run script as a super user? May be . ./ using for run script as a super user.
The difference between the two invocations is that ./import.sh is executing import.sh as a program, and . ./import.sh is evaluating it in your shell.
If "import.sh" were an ELF program (a compiled binary, not a shell script), . ./import.sh would not work.
If import.sh had a shebang at the top (like #!/bin/perl), you'd be in for a nasty surprise and a huge number of error messages if you tried to do . ./import.sh - unless the shebang happened to match your current shell, in which case it would accidentally work. Or if the Perl code were to somehow be a valid Bash script, which seems unlikely.
. ./import.sh is equivalent to source import.sh, and doesn't require that the file have the execute bit set (since it's interpreted by your already-running shell instead of spawned via exec). I assume this is the source of your error. Another difference is that ./import.sh runs in the current shell instead of a subshell, so any non-exported environment variables will affect the shell you used for the launch!
So, they're actually rather different. You usually want to ./import.sh unless you know what you're doing and understand the difference.
./import.sh executes the shell script in a new sub shell shell.
. ./import.sh executes the shell script in the current shell.
The extra . denotes the current shell.
./import.sh runs the script as a normal script - that is, in a subshell. That means it can't affect your current shell in any way. The paths it's supposed to import won't get set up in your current shell.
The extra ., which is equivalent to source, runs the script in the context of your current shell - meaning it can modify environment variables, etc. (like the paths you're trying to set up) in the current 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.
The . ./import.sh "sources" the script, where as simply ./import.sh just executes it.
The former allows you to modify the current environment, where the later will only affect the environment within the child execution.
The former is also equivalent to (though mostly Bash-specific):
source ./import.sh
help source yields:
source: source filename [arguments]
Execute commands from a file in the current shell.
Read and execute commands from FILENAME in the current shell. The
entries in $PATH are used to find the directory containing FILENAME.
If any ARGUMENTS are supplied, they become the positional parameters
when FILENAME is executed.
Exit Status:
Returns the status of the last command executed in FILENAME; fails if
FILENAME cannot be read.