Possible Duplicate:
Using ‘.’ to execute files in bash
I was trying to figure out how to export my environmental via script instead of changing my .bashrc file.
I found this old useful post that said:
Variables can only be exported to subordinate processes, you can’t
pass them back up to the parent. If you really want your script to
affect the parent shell’s environment, run the script as. ./yourprogram
I just want to know what the difference is between . ./script and ./script?
When I look at it, they booth mean to me, run the script from the current directory?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
./script runs a file called ‘script’ in the location ./ – which translates to ‘here’ (i.e. the current directory). That script is executed in a sub-shell, and anything that script does to the environment is lost when the sub-shell ends.
. ./script tells the current shell to execute a file called ‘script’ in the location ./ in the current shell without a sub-shell, so anything it changes in the environment remains when the script stops.
. is shorthand for the command source. You can lookup source with man (man source).
/home/bob/script is the same as ./script if you are in the directory /home/bob
. /home/bob/script is the same as . ./script if you are in the directory /home/bob
Method 2
./script means running the file script which is in the current directory. Generally shell while running a script first calls fork() and exec() i.e. the script will run in child process ( i.e sub-shell )
. ./script is similar to source ./script which means running the script in the current shell without any fork()
Method 3
The first is a shell command . followed by a path. The second is just a path.
The shell command . “sources” the file that follows into the current shell session. So variables that are set in ./yourprogram will then be visible in the session or script that executed . ./yourprogram.
The second command, on the other hand, just requests that ./yourprogram be executed. This will only work if ./yourprogram has the appropriate execute permissions, and is either
- a binary
- a script in some language that begins with a “shebang”
line, for example#!/bin/shor#!/usr/bin/python - or it’s a
script in the language of the current shell, lacks a shebang line,
but the current shell defaults to executing script files in a child
shell in such cases
In none of those events will changes to shell/environment variables performed by ./yourprogram be visible afterwards in the calling script or session.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0