What is the difference between ./script and . ./script? [duplicate]

Question

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?

Answer 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

Answer 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()

Answer 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

1. a binary
2. a script in some language that begins with a "shebang" line, for example #!/bin/sh or #!/usr/bin/python
3. 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.